Re: [SC-L] informIT: Modern Malware

2011-03-26 Thread John Wilander
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 gun...@arctecgroup.net 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

2011-01-23 Thread John Wilander
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.comCo-organizer Global Summit,
http://www.owasp.org/index.php/Summit_2011
http://www.owasp.org/index.php/Summit_2011Conf 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] OWASP AppSec Research 2010 - Call for Papers

2009-06-24 Thread John Wilander
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)

2008-11-25 Thread John Wilander
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.
___


[SC-L] Web Services vs. Minimizing Attack Surface

2006-08-15 Thread John Wilander
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

2006-07-21 Thread John Wilander
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