1 / 53

SEng 5861: Software Architecture

SEng 5861: Software Architecture. Lecture 10 Dr. Michael Whalen Fall 2010. Topics for Today. Questions / Comments from last week Team Presentations on 12/3 Security Perspective Short Introduction to Service Oriented Architectures More from Leon on 12/17. Updates.

acacia
Download Presentation

SEng 5861: Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SEng 5861: Software Architecture Lecture 10 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

  2. Topics for Today • Questions / Comments from last week • Team Presentations on 12/3 • Security Perspective • Short Introduction to Service Oriented Architectures • More from Leon on 12/17 SEng 5861 - Mike Whalen

  3. Updates • Coming up to the end of term • Remaining Lectures: 11/20, 12/3. 12/17 • 12/17 will be final • 12/3 will be presentations and final review • So…this is the last ‘content’ lecture SEng 5861 - Mike Whalen

  4. Team technical presentations SEng 5861 - Mike Whalen

  5. Why? People skills are important You must earn and maintain the confidence of all of your stakeholders from senior management and users to developers, third parties, and operational staff • Often, your interactions with stakeholders are through presentations • Management: proposals, progress reports • Technical team meetings • You will be judged on the quality of the presentation • Knowing your audience is important • Being able to concisely summarize why they should care in a short presentation is critically important. SEng 5861 - Mike Whalen

  6. Architecture Presentations • Two team presentations during the semester • One 10 minute project proposal • One 20 minute technical talk • Presentations should be formatted differently for different audiences • Every group member should be involved (speak) in at least one of the talks SEng 5861 - Mike Whalen

  7. Technical Presentation • Audience: technical stakeholders • Depends on viewpoint chosen • Entire class will act as your stakeholders • Purpose: convey information • Provide technical overview of original model and your change to it • Persuade users that it is the right solution • Time: 20 minutes • Shoot for being able to deliver in ~15 minutes in case of questions SEng 5861 - Mike Whalen

  8. Technical Presentation • Present one of the viewpoints in your architecture document + extension • Should be enough time to give flavor of architecture • Expect technical questions • E.g., questions related to comparison of alternatives SEng 5861 - Mike Whalen

  9. Security perspective SEng 5861 - Mike Whalen

  10. Security Security is the set of processes and technologies that allow the owners of resources in the system to reliably control who can perform actions on particular resources Policy Mechanism Threat Systems Uses Executes Tasks Reads/ Modifies Information SEng 5861 - Mike Whalen

  11. Security is Risk Management SEng 5861 - Mike Whalen

  12. Security Policies • Defines different kinds of principals • Defines different kinds of resources • Defines a matrix of access rights from principals to resources • Enterprise-level policies become very large • May involve: • Inheritance (manager is a employee) and • Delegation: (while Alice is gone, Bob can act as manager) • Time Windows: Bob can act as manager only until December 1st A security policy defines security-related constraints that the system should enforce. SEng 5861 - Mike Whalen

  13. Security Policy Activities • Identify the Principals • Identify the Sensitive Resource Classes • Identify Actions on Sensitive Resources • Identify Sensitive System Operations • Create the Access Control Matrix • Identify Integrity Requirements SEng 5861 - Mike Whalen

  14. Access Control Matrix Each cell defines a list of allowed activities for this principal on this resource. Examples would include {read, write, execute, update, audit, migrate, resize, etc} Resources may be objects the system manipulates or may be configuration / supervisory aspects of the system itself SEng 5861 - Mike Whalen

  15. Security Threats • It may also document a rationale as to why • Identify (as much as possible) threats to security policy • Password cracking • Network attacks • Denial of service • Exploitation of software bugs (buffer overflows) • Social Engineering • Malicious Insider A security threat describes a possible way that an attacker may breach security constraints. SEng 5861 - Mike Whalen

  16. Security Threat Activities • Start from list of sensitive resources • Attempt to determine, for each resource: • Who is likely to try to infringe the security policy? • How will they try to do so? • What are the attackers’ main characteristics? • Motivation, sophistication, resources • What are the consequences? SEng 5861 - Mike Whalen

  17. Attack Tree Models • Provide well documented method of exploring every possibility an adversary has (technical and non-technical). • Data presentation in tree format allows: • Easy gap identification • Selective elaboration based on location in the tree • Ability to assign attributes for nodes of the tree: • Impact of the attack • Ease of attack execution • Cost of the attack • Presence of countermeasures (such as best practices) • Access/trust requirements to conduct attack http://www.ddj.com/documents/s=896/ddj9912a/9912a.htm http://www.cert.org/archive/pdf/01tn001.pdf from: www.ietf.org/proceedings/55/slides/rpsec-3/rpsec-3.ppt

  18. Attack Tree Example Attack: OR1. Unlock door with key OR1. Steal Key 2. Social Engineering OR1. Borrow key 2. Convince locksmith to unlock door 2. Pick lock 3. Break window 4. Follow authorized individual into building OR1. Act like you belong and follow someone else 2. Befriend someone authorized outside a building 3. Appear in need of assistance (such as carrying a large box) AND4. Wear appropriate clothing for the location Goal: Gain unauthorized physical access to building from: www.ietf.org/proceedings/55/slides/rpsec-3/rpsec-3.ppt

  19. Security Mechanisms • Authentication: password, biometric, key card, public/private key • Network: Virtual private networks • Database: DB authentication • Detection: Logging and audit, data mining, statistical analysis The security mechanisms in a system are the set of technologies, configurations settings, and procedures required to enforce the rules established by the security policy SEng 5861 - Mike Whalen

  20. Security Mechanisms • Define mitigations for the risks identified as threats • There are many possible mitigation activities depending on the identified threats SEng 5861 - Mike Whalen

  21. How would you mitigate against the following? Attack: OR1. Unlock door with key OR1. Steal Key 2. Social Engineering OR1. Borrow key 2. Convince locksmith to unlock door 2. Pick lock 3. Break window 4. Follow authorized individual into building OR1. Act like you belong and follow someone else 2. Befriend someone authorized outside a building 3. Appear in need of assistance (such as carrying a large box) AND4. Wear appropriate clothing for the location Goal: Gain unauthorized physical access to building from: www.ietf.org/proceedings/55/slides/rpsec-3/rpsec-3.ppt

  22. Security Mechanism Notes • Many mitigations require social rather than technological solutions • Make sure people think about security • Have occasional assessments of social aspects of security • Mitigations should include identification of possible attacks SEng 5861 - Mike Whalen

  23. Airport parking Security example SEng 5861 - Mike Whalen

  24. Airport Parking Controller • You are asked to build the automated parking system at MSP airport • Support ePark: • Also support ticketed parking: user receives a ticket and pays either by credit card or cash Simply insert your credit or debit card into the card reader at the ramp entrance. This will record the time you entered airport parking. Use the same credit or debit card to pay at an ePark® exit lane. The system is fully automated; there is no waiting in line for a cashier. SEng 5861 - Mike Whalen

  25. Determine sensitive data • Determine principals • Determine operations on sensitive data • Create ACM • Create attack tree for one piece of sensitive data SEng 5861 - Mike Whalen

  26. Mapping security to perspectives SEng 5861 - Mike Whalen

  27. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  28. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  29. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  30. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  31. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  32. SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

  33. Assess Risks SEng 5861 - Mike Whalen

  34. Security Risk Assessment • For each security risk: • Estimate cost for successful attack • Estimate likelihood (%) of successful attack • Attack tree can be used to “roll up” number • Likelihood should be over some time period • Notional cost = (cost estimate) * likelihood • Determine whether notional risk is acceptible • If not, determine add’l mitigations SEng 5861 - Mike Whalen

  35. security tactics SEng 5861 - Mike Whalen

  36. Apply Recognized Security Principles • Principle of least privilege • Secure the weakest link • Defend in depth • Separate and compartmentalize • KISS • Avoid obscurity • Use secure defaults • Fail secure • Assume external entities are untrusted • Audit SEng 5861 - Mike Whalen

  37. Authenticate Principals • Principals (roles), not users • Same person may require multiple logins depending on desired privilege • E.g. root vs. ‘normal’ user • Determine mechanism to ensure principal is authentic based on risk • May be different depending on principal class • Critical thing: each principal can be reliably identified during system use SEng 5861 - Mike Whalen

  38. Authorize Access • Verify principal’s right to access sensitive resource for each sensitive operation • Ensure that access mechanisms correctly implement access control matrix • Software/system testing • Ensure access control matrix ensures security policy • Organizational review SEng 5861 - Mike Whalen

  39. Ensure Information Secrecy • Secrecy: only principals allowed by access control matrix can read information • Problem: Information is often transmitted within the system • The ‘system’ may exist across organizational boundaries or the internet • Sensitive information must be protected (encrypted) once it moves outside the authorization control of the system in which it is stored. SEng 5861 - Mike Whalen

  40. Ensure Information Integrity SEng 5861 - Mike Whalen

  41. Ensure Accountability • Many systems require users to be accountable for their actions • Two forms of accountability • Auditing: record logs of operations that can be used to establish user actions • Non-repudiation: ability to definitively identify message sender in such a way as to not be plausibly deniable • Digital signing / PKI SEng 5861 - Mike Whalen

  42. ..And more • Integrate security technologies • Provide security administration • Use third party infrastructure SEng 5861 - Mike Whalen

  43. Service-orientedArchitectures SEng 5861 - Mike Whalen

  44. In the Beginning… SEng 5861 - Mike Whalen

  45. Early Business Software • Business and Government discovered the value of computing • Business requirements were captured and programmed • Applications were designed for specific departments / business needs SEng 5861 - Mike Whalen

  46. Problem: Silo Apps SEng 5861 - Mike Whalen Image provided byWill Kellogg

  47. Silo Apps • Each application is self contained • One view of user interaction • Difficult to find clean integration points • Lack of standards makes it difficult to integrate • Leads to duplication • Applications contain nearly duplicate functionality: authentication, business logic, storage mgmt, logging • Business units have nearly-duplicate applications SEng 5861 - Mike Whalen

  48. Motivating Desires for Change • Reuse of existing software assets • Integration between separately developed business applications • …Using different languages • …Using heterogeneous hardware • Easily support corporate change • mergers / acquisitions • reorganization SEng 5861 - Mike Whalen

  49. SOA Introduction • Move to SOA.ppt by ArnonRotem-Gal-Oz SEng 5861 - Mike Whalen

  50. Service Management • Security • Deployment • Logging • Dynamic rerouting • Maintenance SEng 5861 - Mike Whalen

More Related