A couple days ago I received the question and asked here on this blog Why doesn't SAST have better Framework support (for example Spring MVC)? (if don't don't what SAST means, see What does SAST mean? And where does it come from?)
I wrote the answer below on that day, but since I also posted this question to the O2 mailing list I wanted to give some space for others to chip in with their views (which they did, namely John Steven who I will reply to later):
Tuesday, 25 October 2011
Mea culpa: How I abused the OWASP rules on presenter's slides
After I posted my presentation and slides the OWASP Brazil AppSec presentation on "Making Security Invisible by Becoming the Developer's Best Friends" , I was reminded that a couple slides on that presentation break the OWASP rules for conference presentations which are very well established.
In fact, they’re right in the speaker agreement, which I totally violated.
"...Speakers are encouraged to include their contact information when introducing themselves, but may NOT include their logo on any visual and handout materials. Speakers are to avoid any appearance of commercialism in their session and presentations are to be of a technical or solutions emphasis. Further, I understand that the program tracks of the conference/event/chapter are an educational event, not a sales or marketing platform. I agree that my presentation(s) will be an objective review of the topic on which I am presenting, and will not contain any content that is a sales or promotional pitch for any specific product(s) or company(ies). My materials will also be reflective of the current status of the topic(s) I am addressing...."
Clearly the initial slide about SI breaks this, and my mistake was in thinking that tagging it with an 'Advertising' tag made it better (the next slides, although covering Common Criteria content released free by SI, in hindsight are also, too much on the marketing/sales side).
And yes, although there have been worse offenders in the past, that is no excuse and I should know better.
Sorry for this...
(I'm currently in a location with slow internet connection, but once I'm back to land I will update the slides accordingly)
In fact, they’re right in the speaker agreement, which I totally violated.
"...Speakers are encouraged to include their contact information when introducing themselves, but may NOT include their logo on any visual and handout materials. Speakers are to avoid any appearance of commercialism in their session and presentations are to be of a technical or solutions emphasis. Further, I understand that the program tracks of the conference/event/chapter are an educational event, not a sales or marketing platform. I agree that my presentation(s) will be an objective review of the topic on which I am presenting, and will not contain any content that is a sales or promotional pitch for any specific product(s) or company(ies). My materials will also be reflective of the current status of the topic(s) I am addressing...."
Clearly the initial slide about SI breaks this, and my mistake was in thinking that tagging it with an 'Advertising' tag made it better (the next slides, although covering Common Criteria content released free by SI, in hindsight are also, too much on the marketing/sales side).
And yes, although there have been worse offenders in the past, that is no excuse and I should know better.
Sorry for this...
(I'm currently in a location with slow internet connection, but once I'm back to land I will update the slides accordingly)
Sunday, 23 October 2011
What does SAST mean? And where does it come from?
After I posted Why doesn't SAST have better Framework support (for example Spring MVC)? I received the question "What is SAST?" (which is a valid question since a Google search today for SAST returns some hilarious answers)
SAST means Static Analysis Software Testing , and (I believe) it was originally coined by Gartner when they published their Magic Quadrant for Static Application Security Testing report (first version in 2009).
SAST is basically what we usually (in the web world) call Static Analysis of source code (i.e. White Box tools). It cousin is DAST (Dynamic Application Security Testing) and is what we call Pentesting (i.e. BlackBox tools). Google's DAST search results are also funny. Here is a more detailed answer on the difference between SAST and DAST.
SAST means Static Analysis Software Testing , and (I believe) it was originally coined by Gartner when they published their Magic Quadrant for Static Application Security Testing report (first version in 2009).
SAST is basically what we usually (in the web world) call Static Analysis of source code (i.e. White Box tools). It cousin is DAST (Dynamic Application Security Testing) and is what we call Pentesting (i.e. BlackBox tools). Google's DAST search results are also funny. Here is a more detailed answer on the difference between SAST and DAST.
Why doesn't SAST have better Framework support (for example Spring MVC)?
I received this question today, and before I answered it, I was wondering if you guys wanted to have a go at it first:
"...I was reading over some of your blog entries, that made me thinks about the current state of SAST regarding the current frameworks.
I've been aware for a long time that SAST do not handle properly framework-level information. In the case of Spring MVC, the tools just don't get the data flow, etc.
Since you worked at Ounce before, do you know any particular reason why they didn't want to fo into that direction? I mean, this is a solvable problem (you somewhat show how to do that in O2). Even if they would need to implement new front-ends, this is still a very important task to be done if they wanted to compete directly with Fortify (especially since F. doesn't get it either)....
Saturday, 22 October 2011
Mozmill looks really interresting
Anybody tried Mozmill? https://developer.mozilla.org/en/Mozmill and https://developer.mozilla.org/en/Mozmill/First_Steps/Tutorial%3A_Introduction_to_Mozmill
It looks very powerful and it could be a great way to write 'browser-based usability+security unit tests'
O2 needs to support it :)
Example of O2 being used to create a PDF from a list of users
One of the powers of O2 is that is allows the automation of repetitive tasks via scripts
This usually means automating some Web Vulnerability Browser workflow or an specific Static Analysis of source code.
This usually means automating some Web Vulnerability Browser workflow or an specific Static Analysis of source code.
Thursday, 20 October 2011
I need a .Net and JQuery developer based in London
Let me know if you are or know of a great .Net and JQuery developer in London.
SI is going to hire an extra resource to work with me on TeamMentor so please connect the dots :)
SI is going to hire an extra resource to work with me on TeamMentor so please connect the dots :)
Microsoft All-In-One Code Framework (should the OWASP .NET community be involved?)
Anybody tried the Microsoft All-In-One Code Framework ?
It looks like a way to distribute sample apps (for example this ASP.NET AJAX web chat application ) and I wonder how much security thinking (and review) has occurred?
If we are looking for a place to help .NET developers to write secured code, maybe this is a great place for us (OWASP) to be involved.
What do you think?
A comment on "Making Security Invisible by Becoming the Developer's Best Friends"
After my "Making Security Invisible by Becoming the Developer's Best Friends" post, Daniel posted a reply on his blog, and here are my comments on it (as posted on his blog):
Hi Daniel, Thanks for your comments, I think you make a good representation of the security camp that defends that "security is EVERY developer's business" which although well intended, unfortunately doesn't scale, and, in fact it doesn't work.
We will never achieve secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc...
Note that I didn't say that NOBODY should be responsible for an Application's security. Of course that there needs to be a small subset of the players involved that really cares and understands the security implications of what is being created.
The core idea is that developers should be using Frameworks, APIs and Languages that allow them to create secure applications by design (where security is there but is invisible to developers). And when they (the developers or architects) create a security vulnerability, at that moment (and only then), they should have visibility into what they created (i.e. the side effects) and be shown alternative ways to do the same thing in a secure way.
The other idea that I'm trying to push our (the application security) industry to adopt, is this concept: "One can't protect/analyze what is not understood, so application security teams create models (and tools) that help them to visualize and understand how the apps works, and since this 'application visualization metadata' is also VERY valuable to developers, let's work together (devs+qa+appsec) so that we can embed application security knowledge and workflows into the SDL"
For example, a very good and successfully example of making security 'invisible' for developers was the removal of 'buffer overflows' from C/C++ to .Net/Java (i.e. from unmanaged to managed code). THAT is how we make security (in this case Buffer Overflow protection) Invisible to developers
If you are looking for an analogy, "a chef cooking food" is probably the better one. Think of software developers that are cooking with a number of ingredients (i.e. APIs). Do you really expect that chef to be an expert on how ALL those ingredients (and tools he is using) were created and behave? It is impossible, the chef is focused on creating a meal. Fortunately the chef can be confident that some/all of his ingredients+tools will behave in a consistent and well documented way (which is something we don't have in the software world). I like the food analogy because, as with software, one bad ingredient is all it takes to ruin it.
Hi Daniel, Thanks for your comments, I think you make a good representation of the security camp that defends that "security is EVERY developer's business" which although well intended, unfortunately doesn't scale, and, in fact it doesn't work.
We will never achieve secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc...
Note that I didn't say that NOBODY should be responsible for an Application's security. Of course that there needs to be a small subset of the players involved that really cares and understands the security implications of what is being created.
The core idea is that developers should be using Frameworks, APIs and Languages that allow them to create secure applications by design (where security is there but is invisible to developers). And when they (the developers or architects) create a security vulnerability, at that moment (and only then), they should have visibility into what they created (i.e. the side effects) and be shown alternative ways to do the same thing in a secure way.
The other idea that I'm trying to push our (the application security) industry to adopt, is this concept: "One can't protect/analyze what is not understood, so application security teams create models (and tools) that help them to visualize and understand how the apps works, and since this 'application visualization metadata' is also VERY valuable to developers, let's work together (devs+qa+appsec) so that we can embed application security knowledge and workflows into the SDL"
For example, a very good and successfully example of making security 'invisible' for developers was the removal of 'buffer overflows' from C/C++ to .Net/Java (i.e. from unmanaged to managed code). THAT is how we make security (in this case Buffer Overflow protection) Invisible to developers
If you are looking for an analogy, "a chef cooking food" is probably the better one. Think of software developers that are cooking with a number of ingredients (i.e. APIs). Do you really expect that chef to be an expert on how ALL those ingredients (and tools he is using) were created and behave? It is impossible, the chef is focused on creating a meal. Fortunately the chef can be confident that some/all of his ingredients+tools will behave in a consistent and well documented way (which is something we don't have in the software world). I like the food analogy because, as with software, one bad ingredient is all it takes to ruin it.
Wednesday, 19 October 2011
Webinar on 'How to Break Web Software Security'
Tomorrow (20th October) I'm delivering a Webinar on the topic of 'How to Break Web Software Security' which will cover a number of Application Security vulnerabilities (and live demos)
You can read more details about this webinar and register here http://web.securityinnovation.com/webinar-october/
-------------------------
-------------------------
Webinar abstract:
More than 80% of attacks happen at the application layer and network security isn't the answer. To compound the problem, Web applications employ specialized protocols and languages and suffer from unique problems that very quickly and easily lead to vulnerabilities for the uninformed.
This Webcast will describe and present techniques for breaking (from a security standpoint) web applications and learn methods of mitigation. This talk covers all of the basics (SQL injection, XSS, etc.) but goes beyond that to more advanced and sinister attacks.
This Webcast will describe and present techniques for breaking (from a security standpoint) web applications and learn methods of mitigation. This talk covers all of the basics (SQL injection, XSS, etc.) but goes beyond that to more advanced and sinister attacks.
Topics Covered:
- Why the web is different and what this means to testing
- Dangers of web services
- How to think about security vulnerabilities in web applications
- Techniques for information gathering, client-side attacks, state attacks, data attacks, language attacks, server attacks, authentication attacks
Friday, 14 October 2011
My presentation at OWASP AppSec Brazil: "Making Security Invisible by Becoming the Developer's Best Friends"
Hi, here is the presentation I delivered last week at OWASP's AppSec Brazil conference: OWASP Brazil - Making Security Invisible by Becoming the Developer's Best Friends (also available online at SlideShare)
I think I was able to capture how security tends to be seen by developers, how it is currently a TAX on the SDL and how we need to move Application Security into the 'application visibility' space so that we add value to the entire SDL (and create a positive model where the developers want to engage with us)
After you read the presentation, check out this video which I recorded also in Brazil: A developer's rant about security professionals (he was one of the developers that was at the audience which really related to the problem of receiving security guidance from security 'consultants' that don't understand his app).
The demos showed how O2 allowed this world to exist :)
Let me know what you think of it.
Note: see also this follow up post in response to Daniel's comments (below)
I think I was able to capture how security tends to be seen by developers, how it is currently a TAX on the SDL and how we need to move Application Security into the 'application visibility' space so that we add value to the entire SDL (and create a positive model where the developers want to engage with us)
After you read the presentation, check out this video which I recorded also in Brazil: A developer's rant about security professionals (he was one of the developers that was at the audience which really related to the problem of receiving security guidance from security 'consultants' that don't understand his app).
The demos showed how O2 allowed this world to exist :)
Let me know what you think of it.
Note: see also this follow up post in response to Daniel's comments (below)
Subscribe to:
Posts (Atom)