Re: [SC-L] informIT: Modern Malware
A positive side effect of many vendors being US-based is that the US market takes most of the buzzword marketing hit. :) On a more serious note, I think there really are APTs out there, state-driven and all. The problem is when organizations use the term to get away with sub-standard security or to motivate why they can't tell you any details of a recent hack. We need to define what is required for a threat/an attack to be APT. State-driven and funded? 0-day(s) used? Tailor-made exploit for the target? That way we can at least interpret what RSA and others are saying. Right now I can only interpret their statements as "We got owned but we'll loose too much business if we tell you what happened. Just trust us instead." And I really hope that's not the truth. Continued Business by Obscurity Regards, John Sent from my iPad On 26 mar 2011, at 18:12, Gunnar Peterson wrote: > Advanced = goes through firewall > Persistent = tried more than once > Threat = people trying to get into valuable stuff > > Nothing new to sc-l readers, but a Reasonably good marketing term esp by > infosec standards (yay we get to scare business people with something other > than an auditor's clipboard!); really its all just the collective sound of > infrastructure security people coming to grips with the fact that their > firewall isn't a wall at all, but rather a series of holes. > > -gunnar > > > > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Official OWASP Summit Challenge
Hi OWASPers, WebAppSecers and Secure Coders! The official OWASP Summit Challenge is out – a JavaScript fighting arena where your script should show its name more prominently than its competitors. Check it out: http://makeXORbreak.com By this we start the countdown to one of the most important meetings in application security history. February 8-11 we invite you all to join round-table discussions with industry and research leaders on how to solve XSS and enhance browser security, which appsec metrics work, security of HTML5 and EcmaScript 5 and more. We truly believe that crucial things can happen in a social, productivity-oriented environment. That's why OWASP is going all-in on the Summit. Google will be there. Mozilla will be there. Microsoft will be there. Facebook will be there. PayPal will be there. Apache will be there. The world's top appsec companies will be there. The authors of (my) favorite appsec books will be there. Best thing of all? You are most welcome to join! http://www.owasp.org/index.php/OWASP_Summit_2011 Get going with the Challenge – http://makeXORbreak.com Best regards, John Wilander -- John Wilander, https://twitter.com/johnwilander Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com <http://owaspsweden.blogspot.com>Co-organizer Global Summit, http://www.owasp.org/index.php/Summit_2011 <http://www.owasp.org/index.php/Summit_2011>Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] CFP: OWASP AppSec Research 2010 (Stockholm, Sweden)
*** OWASP APPSEC RESEARCH 2010, 2nd CALL FOR PAPERS *** Submission is now open for the upcoming OWASP AppSec Research conference, June 21-24, 2010 in Stockholm, Sweden -- http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden . * TOPICS OF INTEREST * We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas: • Web application security • Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0, offline support, etc) • Security in web services, REST, and service oriented architectures • Security in cloud-based services • Security of frameworks (Struts, Spring, ASP.Net MVC etc) • New security features in platforms or languages • Next-generation browser security • Security for the mobile web • Secure application development (methods, processes etc) • Threat modeling of applications • Vulnerability analysis (code review, pentest, static analysis etc) • Countermeasures for application vulnerabilities • Metrics for application security • Application security awareness and education * TYPES OF SUBMISSION * 1. Publish or Perish. Peer-reviewed 12 page papers to be published in formal proceedings by Springer-Verlag (Lecture Notes in Computer Science, LNCS). Presentation slides and video takes will be posted on the OWASP wiki after the conference. 2. Demo or Die. A demo proposal should consist of a pdf with a 1 page abstract summarizing the matter proposed by the speaker(s) and 1 page containing demo screenshot(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference. 3. Present or Repent. A presentation proposal should consist of a 2 page extended abstract representing the essential matter proposed by the speaker(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference. Full instructions can be found on the conference webpage http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=CFP. If you have any questions regarding submissions etc, please email john.wilan...@owasp.org. * IMPORTANT DATES * Submission deadline: February 7th 23:59 (Apia, Samoa time). Decision notification: April 7th Conference: June 21st - 24th * PROGRAM COMMITTEE * • John Wilander, Omegapoint and Linköping University (chair) • Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) • Lieven Desmet, Katholieke Universiteit Leuven • Úlfar Erlingsson, Reykjavík University and Microsoft Research • Martin Johns, University of Passau • Christoph Kern, Google • Engin Kirda, Institute Eurecom • Ulf Lindqvist, SRI International • Benjamin Livshits, Microsoft Research • Sergio Maffeis, Imperial College London • John Mitchell, Stanford University • William Robertson, UC Berkeley • Andrei Sabelfeld, Chalmers UT A warm welcome from the OWASP community! Regards, John Wilander *** About OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] OWASP AppSec Research 2010 - Call for Papers
Dear secure coding friends, In exactly one year -- June 21-24, 2010 -- let's all meet in beautiful Stockholm, Sweden. OWASP Sweden, Norway, and Denmark hereby invite you to OWASP AppSec Research 2010. AppSec Research = AppSec Europe This conference was formerly known as OWASP AppSec Europe. We have added 'Research' to highlight that we invite both industry and academia. All the regular AppSec Europe visitors and topics are welcome along with contributions from universities and research institutes. This is the European conference for anyone interested in or working with application security. Co-host is the Department of Computer and Systems Science at Stockholm University, offering a great venue in the fabulous Aula Magna. Call for Papers and Proposals We offer two options: 1. Full papers. Peer-reviewed 12 page papers that will be published in formal proceedings by Springer-Verlag Lecture Notes in Computer Science (final approval pending). 2. Presentation proposals. A presentation proposal should consist of a 2-page position paper representing the essential matter proposed by the speaker(s). Proposals must include sufficient material for the reviewers to make an informed decision. Topics of Interest We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas: Web application security Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0, offline support, etc) Security in web services, REST, and service oriented architectures Security in cloud-based services Security of frameworks (Struts, Spring, ASP.Net MVC etc) New security features in platforms or languages Next-generation browser security Security for the mobile web Secure application development (methods, processes etc) Threat modeling of applications Vulnerability analysis (code review, pentest, static analysis etc) Countermeasures for application vulnerabilities Metrics for application security Application security awareness and education Submission Deadline and Instructions Submission deadline is Sunday February 7th 23:59 (Apia, Samoa time). Submissions should be at most 12 pages long in the Springer LNCS style for "Proceedings and Other Multiauthor Volumes". Templates for preparing papers in this style for LaTeX, Word, etc can be downloaded from: http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0. Full papers must be submitted in a form suitable for anonymous review: remove author names and affiliations from the title page, and avoid explicit self-referencing in the text. Program Committee John Wilander, Omegapoint and Linköping University (chair) Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) Andrei Sabelfeld, Chalmers UT Engin Kirda, Institute Eurecom Lieven Desmet, Katholieke Universiteit Leuven Martin Johns, University of Passau Christoph Kern, Google Sergio Maffeis, Imperial College London Organizing Committee John Wilander, chapter leader Sweden (chair) Mattias Bergling (vice chair) Alan Davidson, Stockholm University/Royal Institute of Technology (co-host) Ulf Munkedal, chapter leader Denmark Kåre Presttun, chapter leader Norway Stefan Pettersson (sponsoring coordinator) Carl-Johan Bostorp (schedule and event coordinator) Martin Holst Swende (coffee/lunch/dinner) Kate Hartmann, OWASP Sebastien Deleersnyder, OWASP Board Countdown Challenges -- Free Tickets to Win! There will be a challenge posted on the conference wiki page the 21st every month up until the event. The winner will get free entrance to the conference. What are you waiting for? The first challenge is posted. Go, go, go -- https://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm%2C_Sw eden#AppSec_Research_Challenge_1:_Input_Validation_and_Regular_Expressions. OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org. Welcome to Stockholm next year! Regards, John Wilander ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] The problem with (Java's) Security Policy (Was: Unclassified NSA document on .NET 2.0 Framework Security)
Hi all! I agree with Gunnar on this one. 2008-11-25 18.00, Gunnar Peterson wrote: > maybe the problem with least privilege is that it requires that > developers: > > 1. define the entire universe of subjects and objects > 2. define all possible access rights > 3. define all possible relationships > 4. apply all settings > 5. figure out how to keep 1-4 in synch all the time > > do all of this before you start writing code and oh and there are > basically no tools that smooth the adoption of the above. > > i don't think us software security people are helping anybody out in > 2008 by doing ritual incantations of a paper from the mid 70s that may > or may not apply to modern computing and anyhow is riddled with ideas > that have never been implemented in any large scale systems To the best of my knowledge the security policy framework for Java is more or less unused. Why? Because it's designed for static, once-in-a-lifetime releases of software. Writing the policy manually is infeasible so you need to ... 1. Instrument the code to output what permissions it needs. Typically with a custom SecurityManager that logs all checkPermission() calls. See the paper reference at the end of this email for more info. 2. Drive the application with your testbed to actually get the policy output. Your test cases won't cover all application code so you'll surely miss policy statements. Threading will be a headache here - you need to propagate the security context to all running threads so they all output their needed permissions. 3. Then you need to filter out what policy statements actually come from your application and not from your application server. That's quite easy based on the package names. 4. The next step is to collapse the resulting gigantic policy to something readable, e.g. merging individual file permissions to cover whole folders. A lot of parsing and ad hoc rules applied here. You have to write the collapsing code yourself. Not too nice. 5. Now you need to _review_ the generated policy so that it's compliant with the desired permissions of the application. Any suspicious policy statements will need to be investigated. This is a good driver for code review but that's another question. Code changes because of unwanted permissions means starting all over. 6. Then you merge it with the policy file for the application server. There is one, huh? 7. You dig into the application server documentation to sort out policy deployment. 9. System and acceptance testing. You might notice that the server's own policy doesn't work (server refuses to start). Why? It hasn't been maintained since nobody uses it. Good luck on updating that one. Here the missed policy statements from 2 hopefully will be found as security exceptions. Update testbed and re-iterate the whole process. 10. Time to ship. Off you go! 11. Darn! We need to patch a few things and release version 1.3.1. Guys, we need to start all over again with the policy. Anyone up for it? If I'm totally wrong please tell me what to do. I'd really like to deploy maintainable security policies. Mark Petrovic has written some good things on this issue (http://www.onjava.com/pub/a/onjava/2007/01/03/discovering-java-security-req uirements.html). Regards, John Wilander -- John Wilander, Security Architect www.omegapoint.se ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Web Services vs. Minimizing Attack Surface
Thanks for all the replies so far! I would just like to comment on Holger Peine's and Mike Hines' viewpoints. [EMAIL PROTECTED] wrote: > I don't see a conflict here: A web service (just as any > network-accessible > service, no matter whether programmed using sockets, Java RMI, SOAP or > whatever) is _intended_ to provide some function to the outside world, > so you have to open _some_ door into your system. The advice about > minimizing the attack surface is about not opening any doors you don't > really need (or worse, didn't even intend to open). As you say, any kind of system is _intended_ to provide some function. But security bugs often hide in unintended, undocumented or unknown functionality. By increasing the attack surface you also increase the risk of adding unknown functions. Mike Hines commented on web services running everything through port 80 (HTTP) as negating "... any value of firewalls and most likely intrusion detection systems". Indeed, web services tunnel a lot of functionality through port 80, effectively hiding it from many system monitoring defense measures. The security will rely on validating SOAP envelopes and prevention at the application/run-time system level. It seems to me like a huge burden. Regards, John John Wilander, PhD student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] Web Services vs. Minimizing Attack Surface
Hi! The security principle of minimizing your attack surface (Writing Secure Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, named pipes etc. that facilitate network communication between applications. Web services and Service Oriented Architecture on the other hand are all about exposing functionality to offer interoperability. Have any of you had discussions on the seemingly obvious conflict between these things? I would be very happy to hear your conclusions and opinions! Regards, John John Wilander, PhD student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
I've actually been using a secure software slogan for a few years, both in teaching and in pitching business. It's taken from Howard and LeBlanc's book "Writing Secure Code": - Security features are not secure features - The statement mesmerizes people and aguably needs a "necessarily" to be more precise. But it's short and does the trick for me---it separates adding security functions from trying to secure all functions in the system (during all phases). Regards, John ____ John Wilander, PhD Student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
