Threat Level: green Handler on Duty: Daniel Wesemann

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Secure languages & frameworks

Published: 2011-11-01
Last Updated: 2011-11-01 19:15:33 UTC
by Russ McRee (Version: 1)
6 comment(s)

Richard S wrote us and asked what information we could offer regarding languages & frameworks that are more suitable for developing secure applications, along with what attributes differentiate them over their less secure counterparts. 

I'll treat this as a starting point for a run on reader comments but will set the ground rules, and throw out some core elements to get the conversation under way.
In the interest of full disclosure, I am not a developer (good at break and assess but not create) and I work for Microsoft.
As such I recuse myself from all but a few strong convictions.
 
First, let's not go for the "this language is so much better than that language" or "that framework s**ks" approach. Instead, let's recognize that there are a wide variety of options and that the approach should be about secure development practices first and foremost.
 
Second, focus your comments and feedback on successes, with examples, while also not disclosing who you work for and the exact applications you refer to; in general terms, what works and why you believe your language/framework of choice is secure to the extent that it is.
 
Above all else, I espouse following an SDL/SDLC practice to include code review and threat modeling, as well as static and runtime analysis, with security checkpoints woven into to delivery schedules. I am of the opinion that this practice precedes the language or framework being used.
One can obviously write terrible code in the same language with which another developer can write the digital equivalent of Fort Knox.
As Swa Frantzen pointed out in a comment on the Critical Control 7 - Application Software Security diary he posted on my behalf, consider embracing "a bottom-up security framework such as OWASP ESAPI (Enterprise Security API).
OWASP ESAPI is available for Java EE, .NET, Classic ASP, PHP, while others are pending release (ColdFusion, C, C++).
 
Richard's line of questions is focused on web application development, and he posed the point that
there is much literature on design patterns & the importance of validation etc., but less on the  subject of secure languages and frameworks.
Again, I contend that this is a function less of there being one or two highly touted languages/frameworks, and more about those that have security-centric libraries to be leveraged for product hardening as well as good developers to do so. 
 
For your consideration (borrowed directly from Richard's inquiry):
1) If you take everything else being equal (defensively designed code with input validation, a hardened infrastructure, firewalls,  TLS, & so on) the question remains : how does  the choice of language & framework impact on the concept of security in depth?
2) What attributes of the language itself enhance security?
3) If "compiled" offers an advantage over "scripted" in this respect, do the likes of C#  have an advantage given the resources dedicated to supporting & securing it? Are compiled apps less vulnerable than scripted apps as a function of source code exposure post-compromise?
 
Also on the table are the challenges around 3rd party plugins for given platforms. I believe that this is always the soft spot in what may be otherwise splendid armor. Insert your favorite weakest link analogy here.
 
I believe a follow-up post will be required here to include references from industry studies that discuss:
  • Number of organizations that use each framework or language for 'secure'  applications
  • Availability & number of security elements built in to the core language / framework
  • Availability & number of 3rd party security elements built (can they be identified as trustworthy)
  • Number of vulnerabilities identified (per month, per year)   
  • Time to fix

So bring it on: tell us via the comment form what works for you and why (don't hesitate to include favorite static/runtime analysis tools).

Russ McRee Twitter

 

 

 

6 comment(s)

Honeynet Project: Android Reverse Engineering (A.R.E.) Virtual Machine released

Published: 2011-11-01
Last Updated: 2011-11-01 04:41:09 UTC
by Russ McRee (Version: 1)
2 comment(s)

Christian (@cseifert) of the Honeynet Project advised us that they've released A.R.E, the Android Reverse Engineering Virtual Machine.

This VirtualBox-ready VM includes the latest Android malware analysis tools as follows:

  • Androguard
  • Android sdk/ndk
  • APKInspector
  • Apktool
  • Axmlprinter
  • Ded
  • Dex2jar
  • DroidBox
  • Jad
  • Smali/Baksmali

A.R.E. is freely available from http://redmine.honeynet.org/projects/are/wiki

Given the probable exponential growth in mobile malware, A.R.E. presents an opportunity to test, learn, and analyze.

Russ McRee

Twitter

2 comment(s)
ISC StormCast for Tuesday, November 1st 2011 http://isc.sans.edu/podcastdetail.html?id=2101
Diary Archives