1. © Blackboard, Inc. All rights reserved. Developing Secure Software Bob Alcorn, Blackboard Inc.

2. About Forward-Looking Statements » We may make statements regarding our product development and service offering initiatives, including the content of future product upgrades, updates or functionality in development. While such statements represent our current intentions, they may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

3. Session Outline » Security Overview » Blackboard Academic Suite™ Security Infrastructure » Integrating Security Analysis into the Development Lifecycle » Some Vulnerabilities

4. Oh, … » A bug comes in from the field, demonstrating that code fails to check a permission, and allows a user to delete large swaths of data… » A client reports that failure validate input exposes the ability for a user to view the contents of any file on the system… » Investigation of client performance issues reveals that code performs an expensive operation, but doesn’t handle multiple, repeated requests, resulting in system response crashing… » …How do you proactively address these issues before you get the “oh, ” client call?

5. General Security Principles » Authentication » Who a user is » Authorization » What a user can do » Confidentiality » What a user can see » Non-repudiation » Did a user really perform an action » Availability » The system is ready for user activity

6. Authentication » Verifying users’ identities » The “factors” in authentication… » What a user “is” » What a user “has” » What a user “knows” » One vs. Multi-Factor Authentication » Blackboard as one-factor authentication: » Knows a username/password combination » ATM Card as two-factor authentication: » Has the card AND » Knows the PIN

7. Authorization » Once authenticated, verifying what a user can do » Mandatory Access Control » Determined by system or administrator policy » Discretionary Access Control » Determined by the data owner

8. Authorization – RBAC » Role-based access control » Form of mandatory access control » Blackboard uses “Contextual” RBAC for most operations » Role to use dependent on data being accessed; users can have multiple, even contradictory, roles that are selected based on which data is being accessed

9. Authorization – Discretionary Access Control » Access defined by the data owner » Access Control Lists » ACL is a collection of Access Control Entries » Principal » Privilege

10. Non-Repudiation » The ability to definitively state that a particular transaction has or has not occurred » Logging/Auditing » Signatures

11. Why Model Security? » “I already apply all those principles in my design…” » Bugs in your code… » Bugs in Bb code… » Bugs in infrastructure code…

12. Security in the Development Cycle » Security Analysis in Development is a Risk Mitigation Strategy » You will not find all the bugs… » You will not see all the vulnerabilities… » Your design will have errors of omission and oversight

13. Security Modeling » Techniques to evaluate an application’s overall security or assess the impact of a specific threat » Objectively identify vulnerabilities and address countermeasures » Integrated steps to take in the development process

14. Security Modeling – The Process » Define threats » Consider the data stored in the system, and how it can be misused » Consider the architecture of the system, and the opportunities it affords malicious users » Assess the Impact » You’ve found a vulnerability… what happens if someone actually finds it? How badly would you or your users be affected? » Implement a Countermeasure » Mitigate the risk to the best of your ability – code a preventative action, limit the exposure

15. Defining the Threats » Decompose your application to ask questions about how each use case or application component could go awry » STRIDE » Spoofing Identity » Tampering with Data » Repudiation » Information Disclosure » Denial of Service » Elevation of Privilege » Unlike DREAD, STRIDE is not for “scoring” threats, just for classification in general threat modeling

16. Assessing Vulnerabilities » DREAD aims to quantify a threat » Assign a value between 1 and 10 and use the mean » Damage Potential » 0 – no damage; 10 – complete system damage » Reproducibility » 0 – Almost impossible to reproduce; 10 – can reproduce at any time » Exploitability » 0 – Extremely sophisticated skills required; 10 – anybody with a browser » Affected Users » 0 – No users; 10 – All users (or beyond… think VA data leak) » Discoverability » 0 – Requires source code; 9 – details of exploit are in public domain; 10 – it’s in easily discoverable data in the application itself.

17. Assessing Vulnerabilities » Microsoft Threat Modeling » Identify objectives » Decompose application » Identify threats » Identify vulnerabilities » …repeat » Relies on specific terminology » Asset – resource of value » Threat – Undesired event, such as a data leak » Vulnerability – A specific code or configuration weakness that enables an exploit » Exploit – Attack that utilizes one or more vulnerabilities to realize a threat » Countermeasure – Attempt to reduce probability of attack and impact of a threat

18. Assessing Vulnerabilities » Components work together or independently » Full threat model will use components of the others, such as DREAD to prioritize the identified threats » Process is iterative » A full picture of the application cannot be generated all at once » Vulnerabilities can be found at any level of the application » For more information: OWASP » Open Web Application Security Project

19. OWASP Top-Ten List » Unvalidated Input » Broken Access Control » Broken Authentication and Session Management » Cross-Site Scripting » Buffer Overflow » Injection Flaws » Improper Error Handling » Insecure Storage » Application Denial of Service » Insecure Configuration Management Not all necessarily apply at all times/layers of the application…

20. Unvalidated Input » Client provided data is not properly validated for boundaries, format, etc. » Approaches: » Validate inputs before allowing business processing » Do not rely on client-side validation » Ensure correct error handling

21. Broken Session Management » The system does not properly track sessions, or authentication isn’t properly enforced » Approaches » Within the Building Block itself, treat this as Blackboard’s problem, unless you are creating a custom scheme (as in Web Service authentication)

22. Cross-Site Scripting (XSS) » A user can enter JavaScript that hijacks another user’s browser session » Approaches: » Do not allow markup (e.g., always render as plain text) » Validate/scrub input » blackboard.util.XSSUtil

23. Injection Flaws » A variant of unvalidated input: a script takes request parameters and uses them directly to construct a command passed to another process » Typically realized as SQL Injection – parameters such as column names or where clause fragments are explicitly used in statement construction » Approaches » Validate input » Always use symbolic values » If building statements, always use prepared statements

24. Improper Error Handling » Incomplete error handling which allows inappropriate data to bubble to an end user » Approaches » No unhandled exceptions » Use a webapp error handling policy

25. Denial of Service » A transaction can be abused or overloaded in such a way as to render the system unusable » Approaches » Performance engineering during development » Error handling

26. Others on the Top Ten » Buffer Overflows » Insecure Configuration Management » Insecure Storage » … still important to consider, but less prevalent for the Building Blocks developer

27. …but wait! There’s More! » Unnecessary and Malicious Code » Broken Thread Safety and Concurrent Programming » Unauthorized Information Gathering » Accountability Problems and Weak Logging » Data Corruption » Broken Caching, Pooling, and Reuse

28. Looking Ahead » Apply threat modeling to the application development cycle » During requirements and design, understand the risks and threats » Use a method to evaluate the impact and prioritize; ideally looking at each vulnerability against each asset/threat » Identify critical transactions and risks » Know the countermeasures » Awareness leads to coding practices that eliminate most vulnerabilities – e.g., unvalidated input or code-injection flaws » Other tools to help » XSSUtil – to scrub for potentially harmful markup » Access Control infrastructure to determine trust (e.g., some users are allowed to enter markup)

29. Questions?