umlsec lecture 10 is 2935: developing secure systems courtesy of jan jürjens, who developed umlsec
TRANSCRIPT
![Page 1: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/1.jpg)
UMLSecUMLSec
Lecture 10
IS 2935: Developing Secure Systems
Courtesy of Jan Jürjens, who developed UMLsec
IS 2935: Developing Secure Systems
Courtesy of Jan Jürjens, who developed UMLsec
![Page 2: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/2.jpg)
Courtesy of Jan Jürjens
Critical/High assurance Systems Development
• High quality development of critical systems (dependable, security-critical, real-time,...) is difficult.
• Many systems developed, deployed, used that do not satisfy their criticality/security requirements, sometimes with spectacular failures.
• Many flaws found in design/implementation– CERT reports
No coherent and complete methodology to ensure security in the construction of large general-purpose systems exists …
![Page 3: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/3.jpg)
Courtesy of Jan Jürjens
Quality vs. cost
• Systems on which human life and commercial assets depend need careful development.
• Systems operating under possible system failure or attack need to be free from weaknesses/flaws
• Correctness in conflict with cost.• Thorough methods of system design not used if
too expensive.
![Page 4: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/4.jpg)
Courtesy of Jan Jürjens
Model-based Security
• Goal: – Make the transition from
human ideas to executed systems easy
– Increase quality/assurance with bounded time-to-market and cost.
Requirements
Models
Code
![Page 5: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/5.jpg)
Courtesy of Jan Jürjens
Goal: Secure by Design
Consider critical properties• from very early stages• within development context• taking an expansive view • seamlessly throughout the development lifecycle.
High Assurance/Secure design by model analysis.
High Assurance/Secure implementation by test generation.
![Page 6: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/6.jpg)
Courtesy of Jan Jürjens
Model-based Security Engineering
Combined strategy:• Verify models against
requirements• Generate code from models
where reasonable• Write code and generate
test sequences otherwise.
Requirements
Models
Code
Verify
Code Gen. Test Gen.
![Page 7: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/7.jpg)
Courtesy of Jan Jürjens
Secure by design
• Establish the system fulfills the security requirements– At the design level– By analyzing the model
• Make sure the code is secure– Generate test sequences from the model
![Page 8: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/8.jpg)
Courtesy of Jan Jürjens
Using UML
• UML– Provides unprecedented opportunity for high-
quality and cost- and time-efficient high-assurance systems development:
• De-facto standard in industrial modeling: large number of developers trained in UML.
• Relatively precisely defined • Many tools (specifications, simulation, …).
![Page 9: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/9.jpg)
Courtesy of Jan Jürjens
Challenges
• Adapt UML to critical system application domains.
• Correct use of UML in the application domains.
• Conflict between flexibility and unambiguity in the meaning of a notation.
• Improving tool-support for critical systems development with UML (analysis, …).
![Page 10: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/10.jpg)
Courtesy of Jan Jürjens
UML Extension Goals
• Extensions for high assurance systems development.– evaluate UML specifications for weaknesses in design– encapsulate established rules of prudent
critical/secure systems engineering as checklist– makes available to developers not specialized in
critical systems– consider critical requirements from early design
phases, in system context– make certification cost-effective
![Page 11: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/11.jpg)
Courtesy of Jan Jürjens
The High-assurance design UML profiles
• Recurring critical security requirements, failure/adversary scenarios, concepts offered as stereotypes with tags on component-level.
• Use associated constraints to evaluate specifications and indicate possible weaknesses.– Ensures that UML specification provides desired level
of critical requirements.
• Link to code via test-sequence generation.
![Page 12: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/12.jpg)
Courtesy of Jan Jürjens
UML - Review
Unified Modeling Language (UML):
• visual modeling for OO systems
• different views on a system
• high degree of abstraction possible
• de-facto industry standard (OMG)
• standard extension mechanisms
![Page 13: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/13.jpg)
Courtesy of Jan Jürjens
Summary of UML Components
• Use case diagram– discuss requirements of
the system
• Class diagram – data structure of the
system
• Statechart diagram– dynamic component
behavior
• Activity diagram– flow of control between
components
• Sequence diagram– interaction by message
exchange• Deployment diagram
– physical environment• Package/Subsystem
– collect diagrams for system part
Current: UML 1.5 (released Mar 2003)
![Page 14: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/14.jpg)
Courtesy of Jan Jürjens
Dependency
subtype
supertype
dependency
![Page 15: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/15.jpg)
Courtesy of Jan Jürjens
UML run-through: Class diagrams
• Class structure of system.• Classes with attributes and operations/signals;
– relationships between classes.
![Page 16: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/16.jpg)
Courtesy of Jan Jürjens
UML run-through: Statecharts
• Dynamic behavior of individual component.
• Input events cause state change and output actions.
event[guard]/actione[g]/a
![Page 17: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/17.jpg)
Courtesy of Jan Jürjens
UML run–through: Activity diagrams
• Specify the control flow between components within the system, at higher degree of abstraction than state-charts and sequence diagrams.
For each component or
object
Synchronization bar
A special case ofState-chart
A special case ofState-chart
action stateSub-activity
![Page 18: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/18.jpg)
Courtesy of Jan Jürjens
UML run-through: Sequence Diagrams
• Describe interaction between objects or components via message exchange.
![Page 19: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/19.jpg)
Courtesy of Jan Jürjens
UML Deployment diagrams
• Describe the physical layer on which the system is to be implemented.
Logical (connections)
![Page 20: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/20.jpg)
Courtesy of Jan Jürjens
UML Package
• May be used to organize model elements into groups within a physical system
![Page 21: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/21.jpg)
Courtesy of Jan Jürjens
UML Extension mechanisms
• Stereotype – specialize model element using «label».
– Adds security relevant information to model elements
• Tagged value– attach {tag=value} pair to stereotyped element.
• Constraint– refine semantics of stereotyped element.
• Profile: – gather above information.
![Page 22: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/22.jpg)
Courtesy of Jan Jürjens
Basic Security Requirements
Secrecy
Information
Integrity
Availability
Information
Information
![Page 23: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/23.jpg)
Courtesy of Jan Jürjens
Basic Security Requirements II
Information
Authenticity
Sender
Sender
Nonrepudiability
Information
![Page 24: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/24.jpg)
Courtesy of Jan Jürjens
Problems
• Many flaws found in designs of security-critical systems, sometimes years after publication or use.
• Spectacular Example (1997):– NSA hacker team breaks into U.S. Department
of Defense computers and the U.S.electric power grid system. Simulates power outages and 911 emergency telephone overloads in Washington, D.C..
![Page 25: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/25.jpg)
Courtesy of Jan Jürjens
Causes I
• Designing secure systems correctly is difficult.
• Even experts may fail:– Needham-Schroeder protocol (1978)– attacks found 1981 (Denning, Sacco), 1995
(Lowe)
• Designers often lack background in security.
• Security as an afterthought.
![Page 26: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/26.jpg)
Courtesy of Jan Jürjens
Causes II
• “Blind” use of mechanisms:– Security often compromised by circumventing (rather
than breaking) them.– Assumptions on system context, physical
environment.“Those who think that their problem can be solved by simply applying cryptography don`t understand cryptography and don`t understand their problem” (Lampson, Needham).
![Page 27: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/27.jpg)
Courtesy of Jan Jürjens
Difficulties
Exploit information spreads quickly.– Check the stats at CERT– Organizations hesitate to share
• NCFTA addresses this
• No feedback on delivered security from customers– Difficult to expect
![Page 28: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/28.jpg)
Courtesy of Jan Jürjens
Previous approaches
• “Penetrate-and-patch”: unsatisfactory.– insecure
• damage until discovered
– disruptive • distributing patches costs money, destroys
confidence, annoys customers)
• Traditional formal methods: expensive.– training people– constructing formal specifications.
![Page 29: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/29.jpg)
Courtesy of Jan Jürjens
Holistic view on Security
• Saltzer, Schroeder 1975:– “An expansive view of the problem is most
appropriate to help ensure that no gaps appear in the strategy”
– But “no complete method applicable to the construction of large general-purpose systems exists yet” (since 1975)
![Page 30: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/30.jpg)
Courtesy of Jan Jürjens
Requirements on UML extension
Mandatory requirements:• Provide basic security requirements such as
secrecy/confidentiality and integrity.• Allow considering different threat scenarios
depending on adversary strengths.• Allow including important security concepts (e.g.
tamper-resistant hardware).• Allow incorporating security mechanisms (e.g.
access control).
![Page 31: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/31.jpg)
Courtesy of Jan Jürjens
Requirements on UML extension
• Provide security primitives – e.g. (a)symmetric encryption
• Allow considering underlying physical security.• Allow addressing security management
– e.g. secure workflow
• Optional requirements: – Include domain-specific security knowledge
• Java, smart cards, CORBA, ...
![Page 32: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/32.jpg)
Courtesy of Jan Jürjens
UMLsec: general ideas
• Activity diagram – secure control flow,
coordination
• Class diagram – exchange of data
preserves security levels
• Sequence diagram– security-critical
interaction
• Statechart diagram– security preserved
within object
• Deployment diagram– physical security
requirements
• Package– holistic view on
security
![Page 33: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/33.jpg)
Courtesy of Jan Jürjens
Stereotypes
• Central idea – stereotypes• Add security relevant information to model
elements of three kinds– Security assumptions on the physical level of
the systems: e.g., «Internet»– Security requirements on the logical structure
of the system, e.g., «secrecy» or specific data values, e.g., «critical»
![Page 34: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/34.jpg)
Courtesy of Jan Jürjens
Stereotypes
– Security policies that the system parts are supposed to obey; e.g.
• «fair exchange», «secure links», «data security», «no down-flow»
• First two cases– Simply add some additional information to a model
• Third one• Constraints are associated that needs to be satisfied by the
model
![Page 35: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/35.jpg)
Courtesy of Jan Jürjens
UMLsec profile
![Page 36: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/36.jpg)
Courtesy of Jan Jürjens
UMLsec profile
![Page 37: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/37.jpg)
Courtesy of Jan Jürjens
<<Internet>> , <<encrypted>> , …
• Kinds of communication links (resp. system nodes)
• For adversary type A, stereotype s, have– ThreatsA (s) ⊆ {delete, read, insert, access} of
actions that adversaries are capable of.
Default attacker: Stereotype Threatsdefault()
•Internet
•encrypted
•LAN
•smart card
{delete, read, insert}
{delete}
Insider Threat??
![Page 38: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/38.jpg)
Courtesy of Jan Jürjens
Requirements with use case diagrams
• Capture security requirements in use case diagrams.• Constraint:
– need to appear in corresponding activity diagram.
Customer
Sales application
Business
sells goods
buys goods
<<fair exchange>>
![Page 39: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/39.jpg)
Courtesy of Jan Jürjens
«fair exchange»
• Ensures generic fair exchange condition– Avoid cheating
• Constraint: – after a {start} state in activity diagram is
reached, eventually reach {stop} state.
– Cannot be ensured for systems that anattacker can stop completely.
![Page 40: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/40.jpg)
Courtesy of Jan Jürjens
«fair exchange»
• Customer buys a goodfrom a business.
• Fair exchange means:– after payment,
customer iseventually eitherdelivered good orable to reclaimpayment.
“Pay” may be «provable»
![Page 41: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/41.jpg)
Courtesy of Jan Jürjens
<<secure links>> Example
• Ensures that physical layer meets securityrequirements on communication.
• Constraint: – for each dependency d with stereotype s in
{ <<secrecy>> , <<integrity>>, <<high>>} betweencomponents on nodes n, m, have a communication link l between n and m such that
• if s = <<high>> : have ThreatsA (l) is empty.
• if s = <<secrecy>> : have read ∉ ThreatsA (l).
• if s = <<integrity>> : have insert ∉ ThreatsA (l).
![Page 42: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/42.jpg)
Courtesy of Jan Jürjens
<<secure links>> Example
• Given default adversary type, is <<secure links>> provided ?
![Page 43: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/43.jpg)
Courtesy of Jan Jürjens
<<secure links>> Example
• Given default adversary type, constraintfor stereotype <<secure links>> violated:– According to the Threatsdefault(Internet) scenario
• (read is in Threatsdefault(Internet)),
– <<Internet>> link does not provide secrecy against default adversary.
![Page 44: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/44.jpg)
Courtesy of Jan Jürjens
<<secure dependency>>
• Ensure that <<call>> and <<send>>dependencies between components respectsecurity requirements on communicated datagiven by tags {secrecy}, {integrity} and {high}.
• Constraint: – for <<call>> or <<send>> dependency from C to D (for
{secrecy}):• Msg in D is {secrecy} in C if and only if also in D.• If msg in D is {secrecy} in C, dependency is stereotyped
<<secrecy>>.
![Page 45: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/45.jpg)
Courtesy of Jan Jürjens
Example <<secure dependency>>
<<secure dependency>> provided ?
![Page 46: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/46.jpg)
Courtesy of Jan Jürjens
Example <<secure dependency>>
Violates <<secure dependency>> : Randomgenerator and <<call>> dependency do not givesecurity level for random() to key generator.
![Page 47: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/47.jpg)
Courtesy of Jan Jürjens
<<no down–flow>>
• Enforce secure information flow.
• Constraint:– Value of any data specified in {secrecy}
may influence only the values of dataalso specified in {secrecy}.
Formalize by referring to formal behavioral semantics.
![Page 48: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/48.jpg)
Courtesy of Jan Jürjens
Example <<no down-flow>>
<<no down–flow>> provided ?
![Page 49: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/49.jpg)
Courtesy of Jan Jürjens
Example <<no down-flow>>
• <<no down–flow>> violated: partial information on input of high wm() returned by non-high rx().
![Page 50: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/50.jpg)
Courtesy of Jan Jürjens
<<data security>>
• Behavior of Subsystem with this tag respects• Security reqts of data marked <<critical>> enforced
against against A from deployment diagram.
• Constraints:• Secrecy {secrecy} of data preserved against A• Integrity {integrity} of (v, E) preserved against A• Authenticity {integrity} of (a, o) preserved against A• Freshness {integrity} of data in Data U Keys should
be fresh
Assumption: A does not know data being protected
![Page 51: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/51.jpg)
Courtesy of Jan Jürjens
Notation
![Page 52: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/52.jpg)
Courtesy of Jan Jürjens
Example <<data security>>
Variant of TLS (INFOCOM`99):
<<data security>> against default adversary provided ?
TLS goals: Secure channel between client and server-Secrecy and Server Authenticity
![Page 53: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/53.jpg)
Courtesy of Jan Jürjens
Example <<data security>>
Violates {secrecy} of si against default adversary.
Example <<data security>>
![Page 54: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/54.jpg)
Courtesy of Jan Jürjens
<<guarded access>>
• Ensures that in Java, <<guarded>> classes only accessed through {guard} classes.
• Constraints:– References of <<guarded>> objects
remain secret.– Each <<guarded>> class has {guard}
class.
![Page 55: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/55.jpg)
Courtesy of Jan Jürjens
Example <<guarded access>>
• Provides <<guarded access>> :Access to MicSi protected by MicGd.
slot could be “between 1 and 2PM
![Page 56: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/56.jpg)
Courtesy of Jan Jürjens
Does UMLsec meet requirements?
• Security requirements: <<secrecy>> ,…• Threat scenarios: Use Threatsadv(ster).• Security concepts: e.g. <<smart card>> .• Security mechanisms: e.g. <<guarded
access>>.• Security primitives: Encryption built in.• Physical security: Given in deployment
diagrams.• Security management: Use activity diagrams.• Technology specific: Java, CORBA security.
![Page 57: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/57.jpg)
Courtesy of Jan Jürjens
Design Principles
• How principles are enforced– Economy of mechanism
• Guidance on employment of sec mechanisms to developers – use simple mechanism where appropriate
– Fails-safe defaults• Check on relevant invariants – e.g., when interrupted
– Complete mediation• E.g., guarded access
– Open design• Approach does not use secrecy of design
![Page 58: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/58.jpg)
Courtesy of Jan Jürjens
Design Principles
– Separation of privilege• E.g. guarded objects that check for two signatures
– Least privilege• Basically meet the functional requirements as specified; includes an
algorithm to determine least privilege given a functional specification
– Least Common Mechanism• Based on the object oriented approach
– Psychological acceptability• Emphasis on ease of development through a standard too extension
![Page 59: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/59.jpg)
Courtesy of Jan Jürjens
Security Patterns
• Security patterns: use UML to encapsulate knowledge of prudent security engineering.Example:
Does not preserve security of account balance.
![Page 60: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/60.jpg)
Courtesy of Jan Jürjens
Solution: Wrapper Pattern
• Technically, pattern application istransformation of specification.
• Use wrapper pattern to ensure that no lowread after high write.
• Can check this is secure (once and for all).
![Page 61: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/61.jpg)
Courtesy of Jan Jürjens
Secure channel pattern:
• To keep d secret, must be sent encrypted.
Abstract representation
![Page 62: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/62.jpg)
Courtesy of Jan Jürjens
Simple solution
Exchange certificate and send encrypted data over Internet.
Concrete representation
![Page 63: UMLSec Lecture 10 IS 2935: Developing Secure Systems Courtesy of Jan Jürjens, who developed UMLsec](https://reader035.vdocuments.us/reader035/viewer/2022062423/56649e155503460f94aff648/html5/thumbnails/63.jpg)
Courtesy of Jan Jürjens
Exchange certificate and send encrypted data over Internet.