Designed-in Security Some Major Challenges

1. Designed-in SecuritySome Major Challenges Richard A. Kemmerer Security Group Department of Computer Science University of California, Santa Barbara kemm@cs.ucsb.edu Trustworthy Cyberspace May 25, 2011

2. Four Major Challenges • Application specific flaws • How do we write a specification for “there are no application level flaws”? • Dynamic monitoring • How do we design-in an after-deployment environment? • Privacy • How do we help users understand the privacy implications of their actions? • Human in the loop • How do we design-in protection against user errors?

3. Application-level flaws • Need to go beyond simple input vulnerabilities • e.g., SQL injections, cross-site scripting • Software/web framework could check for these • Need to understand more complex vulnerabilities that are specific to a particular application • E.g., applying a discount multiple times or getting an item for free from Amazon • How can these be designed-in?

4. Dynamic Monitoring • Cannot statically prove the absence of all bugs • Need an environment where systems can be continuously monitored after deployment • This environment needs to maintain/guarantee properties that were assumed during the development process • How is this after-deployment monitor designed-in during development?

5. Privacy • Cybersecurity must include privacy too • Foolish users on social networks not only compromise their own private data, but the private data of their friends too • Need to design-in warnings, etc. that let users know when they are jeopardizing their privacy • Need to help users understand the implications of their actions

6. Human in the Loop • How is a formally verified system going to avoid “social engineering”? • How does one specify/verify skinware? • How do we design-in the capability to keep users from doing foolish things to themselves and others?

7. Questions?