State Of Security Podcast Episode 3 is Now Available

Episode 3 of the podcast is now available!

In this edition, I sit down with Bill @Sempf to discuss application security, working with development teams and how to get security and dev folks on the same page. Bill goes so far as to recommend a simple 2 step process that you simply have to hear!

Check it out:

And give us feedback on Twitter (@lbhuston) about this and all other episodes or ideas you have about what you would like us to cover. Thanks for listening!  

Operation Lockdown Update ~ Xojo Web App Security

Just a quick note today to bring you up to date on Operation Lockdown. As many of you may know, MSI began working with Xojo, Inc. a year or so ago, focusing on increasing the security of the web applications coded in the language and produced by their compiler. As such, we gave a talk last year at XDC in Orlando about the project and progress we had made. 

Today, I wanted to mention that we have again begun working on OpLockdown, and we remain focused on the stand-alone web applications generated by Xojo. 

Last week, Xojo released Xojo 2014R3 which contains a great many fixes from the project and our work.

The stand-alone web apps now use industry standard HTTP headers (this was true for the last couple of releases) and have the ability to do connection logging that will meet the compliance requirements for most regulatory guidelines.

Additionally, several denial-of-service conditions and non-RFC standard behaviors have been fixed since the project began.

My team will begin doing regression testing of the security issues we previously identified and will continue to seek out new vulnerabilities and other misbehaviors in the framework. We would like to extend our thanks to the folks at BKeeney Software who have been helping with the project, and to Xojo for their attention to the security issues, particularly to Greg O’Lone, who has been our attentive liaison and tech support. Together, we are focused on bringing you a better, safer and more powerful web application development platform so that you can keep making the killer apps of your dreams!

3 Tough Questions with Bill Sempf

Recently, I caught up over email with Bill Sempf. He had some interesting thoughts on software security, so we decided to do a 3 Tough Questions with him. Check this out! :

 

A short biography of Bill Sempf: In 1992, Bill Sempf was working as a systems administrator for The Ohio State University, and formalized his career-long association with inter-networking. While working for one of the first ISPs in Columbus in 1995, he built the second major web-based shopping center, Americash Mall, using Cold Fusion and Oracle. Bill’s focus started to turn to security around the turn of the century. Internet driven viruses were becoming the norm by this time, and applications were susceptible to attack like never before. In 2003, Bill wrote the security and deployment chapters of the often-referenced Professional ASP.NET Web Services for Wrox, and began his career in pen testing and threat modeling with a web services analysis for the State of Ohio. Currently, Bill is working as a security-minded software architect specializing in the Microsoft space. He has recently designed a global architecture for a telecommunications web portal, modeled threats for a global travel provider, and provided identity policy and governance for the State of Ohio. Additionally, he is actively publishing, with the latest being Windows 8 Application Development with HTML5 for Dummies.

 

Question #1: Infosec folks have been talking about securing the SDLC for almost a decade, if that is truly the solution, why haven’t we gotten it done yet?

For the same reason that there are still bugs in software – the time and money necessary to fix things. Software development is hard, and it takes a long time and lots of money to write secure software. Building security in to the lifecycle, rather than just waiting and adding it to the test phase, is just prohibitively expensive.

That said, some companies have successfully done it. Take Microsoft for instance. For a significant portion of their history, Microsoft was the butt of nearly every joke in the security industry. Then they created and implemented the MSDL and now Microsoft products don’t even show up on the top 10 lists anymore. It is possible and it should be done. It’s just very expensive, and companies would rather take on the risk than spend the money up front.

Question #2: How can infosec professionals learn to better communicate with developers? How can we explain how critical things like SQL injections, XSS and CSRF have become in a way that makes developers want to engage?

There are two fronts to this war: the social and the technical. I think both have to be implemented in good measure to extract any success.

On the social side, infosec pros need to get out of the lab, and start talking at developer conferences. I have been doing this as a good measure since 2010, and have encouraged other community members to do the same. It is starting to work. This year at CodeMash, Rob Gillen and myself gave a day long training on everything from malware analysis to Wi-Fi to data protection. The talk was so popular that we needed to be moved into a bigger room. Security is starting to creep into the developers scope of vision.

Technically, though, security flaws need to be treated just like any other defect. The application security test team needs to be part of QA, treated just like anyone else in QA, given access to the defect tracking system, and post defects against the system as part of the QA process. Until something like the Microsoft SDL is implemented in an organization, integrating security testing with QA is the next best thing.

Question #3: What do you think happens in the future as technology dependencies and complexities ramp up? How will every day life be impacted by information security and poor development/implementations?

More and more applications and devices are using a loosely connected model to support fast UIs and easy functional development. This means more and more business functionality exposed in the form of SOAP and REST services. These endpoints are often formerly internal services that were used to provide the web server with functionality, but are gradually being exposed in order to support mobile applications. Rarely are they fully tested. In the short term future, this is going to be the most significant challenge to application security. In the long term, I have no idea. Things change so fast, it is nearly impossible to keep up.

 

Thanks to Bill for sharing his insights. You can discuss them with him on Twitter, where he is @sempf. As always, thanks for reading!