Ed Moyle 2006 RSA

75 %
25 %
Information about Ed Moyle 2006 RSA
News-Reports

Published on August 27, 2007

Author: Amateur

Source: authorstream.com

Self-Defending Structures: A Model for Design and Implementation :  Self-Defending Structures: A Model for Design and Implementation Session IMP-202 Presented by: Ed Moyle, CTG Believe It or Not… :  Believe It or Not… It’s not just about security. Software bugs cause: Loss of life Race conditions in the 'Therac 25' software lead directly to numerous deaths Loss of money/property The (fortunately) unmanned Ariane 5 rocket exploded due to an overflow condition. The rocket cost $7 billion and the cargo was estimated at $500 million Failure of critical infrastructure An overflow condition shut down a Washington DC hospital on in 1989 Dozens more at the 'Software Horror Stories' Web Page (http://www.cs.tau.ac.il/~nachumd/verify/horror.html) 10-Second Agenda:  10-Second Agenda What’s the issue? Why do we need a new approach? How and why does this approach work? How would somebody start using the approach? Where can someone learn more? What’s the Issue?:  What’s the Issue? We’ve all heard these a million times: Software vulnerabilities ('bugs') are a huge security problem The earlier you find bugs, the cheaper they are to fix The rate of vulnerability discovery is increasing Vulnerabilities cost money: increased maintenance, reduced sales, even a hit to stock price Keeping the bug-rate down costs money Proof Points:  Proof Points In case you don’t believe it, compare: Year-by-year vulnerability discovery rate as per the National Vulnerability Database with Cost of fixing bugs in the lifecycle as per 'The Developer Testing Paradox' (Developer Testing magazine) Result: More bugs found late in the cycle (i.e. production) - the most expensive time! What’s Going On?:  What’s Going On? We’re asking developers to remember to implement more and more complicated security-related rules Memories are fallible Some security-related tasks are complicated and hard to do right 100% of the time Deadlines are tight It’s hard to test for everything, especially when there’s not enough time Other factors might obviate secure code Maintenance programmers Configuration decisions What About Today’s Approaches? :  What About Today’s Approaches? Traditional wisdom says: 'Educate' Developers (e.g. about the evils of calls like 'strcpy()') Audit the code manually or using automated tools Change the development process to make sure that security is integrated into the process These approaches work, but they all have one thing in common… The Common Factor:  The Common Factor The cost the same or more year-over-year: Developers change jobs – new developers come and old ones go. You have to continue to train your development staff on an ongoing basis. Technologies change – new API’s, SDK’s, IDE’s, and all the other acronyms mean you’ll need to keep your auditors (or scanners) up to date on an ongoing basis. Processes change – new development techniques (RUP, MSF, XP, etc.) mean you’ll need to continually need to the way security fits in. Conclusion: Both education and audit are self-perpetuating cost centers that require constant or increasing expenditure over time. Requirements for a New Approach:  Requirements for a New Approach Reduce bugs to the same degree as other approaches Not be mutually exclusive with other efforts Cost less year-over-year Ensure uniformity across development teams Not depend on a particular language Enter Self-Defending Structures:  Enter Self-Defending Structures 'Self Defending Structures' are: Data structures that enforce security policy Data container objects Index or storage data structures (hashtables, dictionaries) Cryptography helper objects/API’s Discussed in the analyst community as 'Application Security Frameworks' Implemented commercially for various application contexts e.g. RSA BSAFE Data Security Manager Does it Work Better?:  Does it Work Better? Abstracts security decisions away from developers The right security things 'just happen' behind the scenes without conscious developer intervention Security functionality becomes centralized, therefore making bugs easier to fix Developer education becomes easier because there are less 'does and don’ts' that developers have to remember Scanning requirement becomes easier because dangerous functionality is centralized in one place Is it Really Cheaper? :  Is it Really Cheaper? Requires an initial investment in terms of development time (con) Reuse means cost goes down over time (pro) Initial investment in building, buying, or researching Long-term savings in management Long-term savings in reduced bugs Periodic development required for updates, but may not be required for incremental API or technology changes (pro and con) Sample Usage:  Sample Usage Data containers that implement memory scrubbing during destruction (or on command) Zeroization of memory before free() or delete (e.g. c/c++) or before we release the last reference (e.g. Java) Population of memory with random data before free() or delete or before releasing the last reference Key container objects that implement expiry or data protection Framework might choose not to encrypt new data with an expired key Framework could maintain keystores for different applications Data that enforces transmission/usage policy Framework could only operate on certain hosts or for certain users Simple Example (High Level View):  Simple Example (High Level View) Let’s start simply: Our [hypothetical] security policy requires that all sensitive data be zeroized when use is concluded; this includes: Cryptographic keys Passwords or user data Regulated Data We don’t want developers to have to remember to make calls to something like memset() every time data is freed Simple Example (Low Level View):  Simple Example (Low Level View) UML 2.0 Sequence Diagram of Self-Defending Memory-Zeroizing Data Container: More Functionality (High Level):  More Functionality (High Level) One addition we can make to the example: Instead of using nulls (zeroizing), we could change the object to write over the data with random data Make the object driven by policy so that developers do not need to worry about: When to scrub the memory How to scrub the memory Changes in security policy impacting memory handling Most importantly, the implementation of memory scrubbing More Functionality (Low Level):  More Functionality (Low Level) UML 2.0 Sequence Diagram of Policy-Driven Self-Defending Memory-Zeroizing Data Container: Design and Implementation Strategies:  Design and Implementation Strategies The easy way: Use object orientation to write code that encapsulates security functionality within container objects (e.g. the last example) Buy (or make use of) an external toolkit that provides some degree of security automation The hard way: Use a procedural language to write code that mirrors an underlying API (like the C API) Getting Part of the Way There:  Getting Part of the Way There Some widely-accessible frameworks do parts of this already: Sun Java JCE Microsoft .NET (e.g. System.security) OpenSSL EVP API RSA BSAFE Data Security Manager They do part of it, but they don’t do all of it… Some Limitations of Existing Frameworks:  Some Limitations of Existing Frameworks JCE provides cryptographic functionality in an opaque way and provides key storage objects, but does not provide zeroization (especially of passwords.) Watch out for: Immutable strings .NET provides cryptographic functionality in an opaque way. Watch out for: Legacy (i.e. CAPI) key storage BSAFE Data Security Manager provides cryptographic functionality, but: 'You gotta play to win' (you get the benefit only where you use the toolkit) Applications:  Applications Enterprise Toolkits – put policy decisions back in the hands of security Commercial Toolkits – simplify product deployment and overall configuration Web Components – defend against external attacks and provide a buffer between UI and underlying services Further Reading (and Shameless Plug):  Further Reading (and Shameless Plug) Some additional resources: RSA BSAFE Data Security Manager documentation or evaluation(http://www.rsasecurity.com/) WASF article series by Thomas Ortega (http://uk.builder.com/) Analyst research (e.g Burton Group research on app security frameworks – http://www.burtongroup.com) Our book Summary/Conclusion:  Summary/Conclusion Development is a hard job, asking developers to remember more details, to learn a new style, or to change the way they work is unrealistic Scanning tools help, but they require both manual intervention, periodic upkeep, and can be highly impacted by technology changes. Self-Defending Structures/Application Security Frameworks increase the security and efficiency of the development process over the long term Self-Defending Structures require an initial investment in time, but ultimately are more effective than other traditional approaches Questions?:  Questions? Thank you!!!! Don’t hesitate to write/call for more information: Ed.Moyle@ctg.com (603)264-1350

Add a comment

Related presentations

Related pages

Edward Moyle | RSA Conference

Edward Moyle. Director, Emerging ... ISACA Ed Moyle is currently Director of Emerging Business and Technology for ISACA. ... Contact RSA Conference
Read more

Ed Moyle | LinkedIn

Ed Moyle is currently Director of Emerging Business and Technology for ISACA. Prior to joining ISACA, Ed was Senior Security Strategist with Savvis and a ...
Read more

Ed Moyle - Google+

Ed Moyle - Information security veteran, writer, speaker, analyst. - Director of Emerging Business and Technology for ISACA - ISACA - Amherst, NH, United ...
Read more

Ed Moyle - ISACA, Director, Emerging Business and Technology

Ed Moyle is director of emerging business and technology at ISACA. Moyle previously worked as a senior security strategist for Savvis and a senior manager ...
Read more

Ed Moyle - 2006 Contributions

Sign-up now. Start my free, unlimited access. Login. All Sites
Read more

RSA: Technical Assistance Circulars -- 2006

Technical Assistance Circulars -- 2006 2006 Technical Assistance Circulars from the Rehabilitation Services Administration (RSA). TAC-06-01 November 21, 2005
Read more

R S A . E D . G O V

ED and HHS, after working with ... The Rehabilitation Services Administration (RSA), ... Fiscal Year 2006. Fiscal Year 2005. Fiscal Year 2004. Fiscal Year ...
Read more

Archived: RSA: 2006 Archived News from RSA

Calendar Year 2006 archived news items from the Rehabilitiation Services Administration (RSA).
Read more