Background: Software Engineering

1. Background: Software Engineering • Software Engineering Involves the Building of Software Systems that are so Large or so Complex that They are Built by a Team • Software Engineering Characterized by • Collection of Theories, Techniques, and Tools • Process of Design, Construct, and Maintain Large Software Products • A Software Engineer Designs Algorithms, Programs Solutions, Tests and Documents Software, Fixes “Bugs”, etc. • An Algorithm Represents a Series of Steps and Actions to Carry Out a Specific Task • An Algorithm is Automated via a Programming Language

2. Background: The Java Language • Java (circa 1997) is a Third Generation, General Purpose, Platform Independent, Concurrent, Class-Based, Object-Oriented Language and Environment • Objects are Used to Model the “Real-World” as you would Find in Everyday Life • Objects Interact and Communicate With Each Other Using Messages • A Class is a Blueprint or Prototype that Defines the Data and the Methods Common to All Objects of a Certain Kind • Classes can be Related to one Another through Inheritance to Share Code and Behavior

3. Background: Mandatory Access Control • Mandatory Access Control (MAC) is a Security Technique that Assigns Security Levels, to Subjects (Clearance) and Objects (Classification) • Clearances/Classifications are: Unclassified (U), Confidential (C), Secret (S), and Top Secret (TS) • Permission of the Subject to Perform Some Operation on the Object Depends on the Relation Between Clearance and Classification as Dictated By: • Simple Security Property: A Subject Can Read an Object Only if its Clearance is Greater Than or Equal to the Classification of That Object • Simple Integrity Property: A Subject Can Write an Object Only if its Clearance is Greater Than or Equal to the Classification of That Object

4. Background: The UML • The Unified Modeling Language (UML) is a Graphical Language for Visualizing, Constructing, and Documenting the Artifacts of a Software System • A Use Case Diagramis a Collection of Use Casesand Actors • A Use Case Describes the Behavior for a Portion of an Application - Capture a Business Process • An Actor Interacts with Use Cases to Represent the Functions that a User is Allowed to Perform

5. Background: The UML • A Sequence Diagram Captures and Represents the Dynamic Behavior of Objects of ClassDiagram. • Model Flow of Control to Illustrate a Typical Scenario or Processing

6. Research: Extending UML with MAC • Security in Software Design is Often Neglected or Deferred Until Later Stages of the Process • Our Approach Extends UML with MAC to Allow a Earlier Integration of Security in the Design Process • Assignment of Security Levels to Use-Cases and Actors Indicate Their Level of Allowable Availability to the Users of the System • As a UML Design is Constructed, Security Assurance Rules (SAR) Check the Dependencies Between the Elements to Keep Security Levels Consistent Our Objective is to Bridget the Gap Between Software Engineers and an Organization‘s Security Personnel in Support of Secure Software Design

7. Actors have Clearances/Use Cases have Classifications Security Assurance Rules (SARs) Dictate When Arrows and Lines can be Drawn in a Use Case Diagram SAR: Actor-Use-Case: An Actor (e.g., Staff) Can be Connected to a Use Case (e.g., Add Question) if its Clearance Dominates (is Greater than or Equal to) Classification SAR: Actors Related by Inheritance: An Child Actor (e.g., Junior Staff) can be Connected to a Parent (e.g., Staff) if the Child Dominates the Parent In Survey Management Questions and Categories of Questions can be Added Actors Limited in their Access to Use Cases (lines) Use Cases Related to One Another (Arrows) Research: Extending UML with MAC

8. MAC Security Assurance Algorithm • Research Focuses on Designing and Implementing a Static Security Assurance Test Algorithm • Use Case Diagrams are Mapped into Directed Graphs According to their Type of Relationship (Actor & Use Case Inheritance, Inclusion, Extension, Use Case – Actor Association) • No Cycles are Allowed in the Directed Graphs • Graphs are Traversed by a Depth-first Search Strategy (DFS-T) with SARs Checked Between Every Two Nodes that are Connected by a Edge • If a SARViolation Occurs, Software Engineer is Informed by a Message and Must Change Security Level(s) of Actors and/or Use Cases

9. MAC Security Assurance Algorithm Typedef Use_Case_Diagram { VA, VU, GAI = (VA, EAI), GUI = (VU, EUI), GUInc = (VU, EUInc), GUExt = (VU, EUExt), GAUC = (VA,VU, EAUC); } Typedef Graph (V, E) where V = {v | v: Node} and E = {(v, w) | v, w: Node} UCD_Graph_Security_Check(G: Graph, Rule: String) { Precount = Postcount = 1; For each v inin G.V { v.visited = false; // reset all nodes as not visited v.pre = v.post = 0;} For each v inin G.V If (not v.visited)then DFS-T(G, Rule, v); } UCase_Diagram_Sec_Check(UCD: Use_Case_Diagram) { UCD_Graph_Security_Check(UCD.GAI, “AIS”); UCD_Graph_Security_Check(UCD.GUI, “UCIS”); UCD_Graph_Security_Check(UCD.GUInc, “UCI”); UCD_Graph_Security_Check(UCD.GUExt, “UCE”); For each actor a in UCD.VA For each edge (a, u) in UCD.EAUC If (!Rule_Check(a, u, “AUC”)) then Report SAR “AUC” violated; }

10. Boolean Rule_Check(src_node, dest_node:Node, R:String){ comp: Boolean; comp = src_node.security_level  dest_node.security_level Switch R // select corresponding rule “AIS”,”UCIS”,”UCI”,”UCE”: return comp; // Actor inheritance - specialization “UCIS”: return comp; // Ucase inheritance - specialization “UCI”: return comp; // Ucase inclusion “UCE”: return (not comp); // Ucase extension “AUC”: return comp; // Actor-Ucase association default: return true; } DFS-T(G: Graph, R: String, v: Node) { v.visited = true; v.pre = precount ++; For each edge (v, w) in G.E { If (!Rule_Check(v, w, R)) then Report SAR R is violated; If (!w.visited) // (v, w) is a TREE-EDGE; DFS-T(G, R, w); Else If (w.post = 0) then Report Cycle; // since (v, w) is a BACK-EDGE; } v.post = postcount ++; } MAC Security Assurance Algorithm

11. Research: Semi-Automated Algorithm • On-Going Research Involves the Design and Development of a Semi-Automated Algorithm that Can Assign Security Levels to Actors/Use-Cases • Suppose a Subset of UML Actors/Use-Cases have Assigned, Consistent MAC Security Levels • Automated Algorithm Maps the Actors/Use-Cases to a Set of Directed Graphs, one for Each Type of UML Relationship • Each Graph is Traversed Recursively with Each Node Compared to It’s Parent and Children to Determine a Set of Allowable Security Levels • Results for Each Graph are Merged to Determine • If Consistent Security Levels for all Nodes Exist • If not, Report All Inconsistencies for Corrections

12. Together Control Center (TCC) • An Sophisticated UML Tool that has Open APIs for JAVA and a Modular Plug-in Structure • TCC Allows Our Own Custom Code to be Added • Custom Code to Define MAC and Enforce SARs • Provides a Tool for Secure Software Design • On-Going Prototyping Effort Supports • Definition of MAC Security Levels for Use-cases, Actors, Classes, and Methods and SARs into TCC • Security Level Assignment for UML Elements • Static Security Tests for the Subsequent Evaluation of a Entire Software Project • Dynamic Security Tests as a Software Design is Created

13. Together Control Center Plug-In (TCC)

14. Together Control Center Plug-In (TCC) The Modified Inspector Panel of TCC, Assigning a MAC Security Level to Actor Staff The Modified Message Pane With Some Mac Warning Messages

15. Together Control Center Plug-In (TCC) Executing the SAR Checks Against UML Design Defining Security Levels and their Names