[SC-L] Mobile phone OS security changing?

2005-04-06 Thread Kenneth R. van Wyk
Greetings,

I noticed an interesting article about a mobile phone virus affecting 
Symbian-based phones out on Slashdot today.  It's an interesting read:

http://it.slashdot.org/it/05/04/06/0049209.shtml?tid=220tid=100tid=193tid=137

What particularly caught my attention was the sentence, Will mobile OS 
companies, like desktop OS makers, have to start an automatic update system, 
or will the OS creators have to start making their software secure?  Apart 
from the author implying that this is an or situation, it's something that 
many of us have been saying for a very long time.  (See my/Mark Graff's 
related op-ed from over a year ago at: 
http://www.securecoding.org/authors/oped/feb132004.php)

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


[SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Kenneth R. van Wyk
Greetings++,

Another interesting article this morning, this time from eSecurityPlanet.  
(Full disclosure: I'm one of their columnists.)  The article, by Melissa 
Bleasdale and available at 
http://www.esecurityplanet.com/trends/article.php/3495431, is on the general 
state of application security in today's market.  Not a whole lot of new 
material there for SC-L readers, but it's still nice to see the software 
security message getting out to more and more people.

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
Quoting from the article:
''You can't really blame the developers,''

I couldn't disagree more with that ...

It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra' or an 'added bonus'
in an application. Typically it's just about programming _correctly_!

The article says it's a 'communal' problem (i.e: consumers should
_ask_ for secure software!). This isn't exactly true, and not really
fair. Insecure software or secure software can exist without
consumers. They don't matter. It's all about the programmers. The
problem is they are allowed to get away with their crappy programming
habits - and that is the fault of management, not consumers, for
allowing 'security' to be thought of as something seperate from
'programming'.

Consumers can't be punished and blamed, they are just trying to get
something done - word processing, emailing, whatever. They don't need
to - nor should. really. - care about lower-level security in the
applications they buy. The programmers should just get it right, and
managers need to get a clue about what is acceptable 'programming' and
what isn't.

Just my opinion, anyway.

-- Michael


On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
 Greetings++,
 
 Another interesting article this morning, this time from eSecurityPlanet.
 (Full disclosure: I'm one of their columnists.)  The article, by Melissa
 Bleasdale and available at
 http://www.esecurityplanet.com/trends/article.php/3495431, is on the general
 state of application security in today's market.  Not a whole lot of new
 material there for SC-L readers, but it's still nice to see the software
 security message getting out to more and more people.
 
 Cheers,
 
 Ken van Wyk
 --
 KRvW Associates, LLC
 http://www.KRvW.com





[SC-L] SOS: Service Oriented Security

2005-04-06 Thread Gunnar Peterson
I have blogged at a high level about some work I am doing on security aspects in
SOA and Web Services. Service Oriented Security (SOS) architecture defines a set
of architectural views, their key consituents, constraints, and relationships.
As the SOA space continues to evolve our software security models will also
need to adapt to these new realities that change or make obsolete (and in some
cases breathe new life into) security mechanisms we have relied on over the
years.

Initial high level overview of SOS architectural views:
http://1raindrop.typepad.com/1_raindrop/2005/03/sos_service_ori.html

I will also be doing a presentation at OWASP Europe on this, and will forward
slides if people are interested.

-Gunnar




RE: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Goertzel Karen
I think it's a matter of SHARED reponsibility. Yes, the programmers and
their managers are directly responsible. But it's consumers who create
demand, and consumers who, out of ignorance, continue to fail to make
the connection between bad software security and the viruses, privacy,
and other issues about which they are becoming increasingly concerned.

The consumer can't be held responsible for his ignorance...at least not
yet. Because practioners of safe software have not done a very good
job of getting the message out in terms that consumers, vs. other
software practioners and IT managers, can understand.

I propose that the following is the kind of message that might make a
consumer sit up and listen:

We understand that you buy software to get your work or online
recreation done as easily as possible. But being able to get that work
done WITHOUT leaving yourself wide open to exploitation and compromise
of YOUR computer and YOUR personal information is also important, isn't
it? 

A number of software products, including some of the most popular ones,
are full of bugs and other vulnerabilities that DO leave those programs
wide open to being exploited by hackers so they can get at YOUR personal
information, and take over YOUR computing resources. 

Why is such software allowed to be sold at all? Because no-one
regulates the SECURITY of the software products that these the companies
put out, least of all the programmers who write that software. And, more
importantly, because you the consumer hasn't been told before that you
can make a difference. You can vote with your feet. 

Demand that the software you use not be full of holes and 'undocumented
features' that can be exploited by hackers. When you go out to buy a
lawn mower, you wouldn't buy a model that has a well-published track
record of its blades flying off. By the same token, you shouldn't buy a
software package that has a well-documented track record of being
successfully compromised by viruses, Trojan horses, and other hacker
tricks.

If we can start to raise consumer awareness in terms that consumers can
understand (avoiding the arcane terminology of software practitioners),
maybe we can start reducing demand for notoriously insecure software
products, and increasing demand for software that is developed with
security in mind.

--
Karen Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
[EMAIL PROTECTED]  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk
 Sent: Wednesday, April 06, 2005 9:40 AM
 To: Kenneth R. van Wyk
 Cc: Secure Coding Mailing List
 Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
 
 Quoting from the article:
 ''You can't really blame the developers,''
 
 I couldn't disagree more with that ...
 
 It's completely the developers fault (and managers). 'Security' isn't
 something that should be thought of as an 'extra' or an 'added bonus'
 in an application. Typically it's just about programming _correctly_!
 
 The article says it's a 'communal' problem (i.e: consumers should
 _ask_ for secure software!). This isn't exactly true, and not really
 fair. Insecure software or secure software can exist without
 consumers. They don't matter. It's all about the programmers. The
 problem is they are allowed to get away with their crappy programming
 habits - and that is the fault of management, not consumers, for
 allowing 'security' to be thought of as something seperate from
 'programming'.
 
 Consumers can't be punished and blamed, they are just trying to get
 something done - word processing, emailing, whatever. They don't need
 to - nor should. really. - care about lower-level security in the
 applications they buy. The programmers should just get it right, and
 managers need to get a clue about what is acceptable 'programming' and
 what isn't.
 
 Just my opinion, anyway.
 
 -- Michael
 
 
 On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
  Greetings++,
  
  Another interesting article this morning, this time from 
 eSecurityPlanet.
  (Full disclosure: I'm one of their columnists.)  The 
 article, by Melissa
  Bleasdale and available at
  http://www.esecurityplanet.com/trends/article.php/3495431, 
 is on the general
  state of application security in today's market.  Not a 
 whole lot of new
  material there for SC-L readers, but it's still nice to see 
 the software
  security message getting out to more and more people.
  
  Cheers,
  
  Ken van Wyk
  --
  KRvW Associates, LLC
  http://www.KRvW.com
 
 
 
 




Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Dave Paris
And I couldn't disagree more with your perspective, except for your 
inclusion of managers in parenthesis.

Developers take direction and instruction from management, they are not 
autonomous entities.  If management doesn't make security a priority, 
then only so much secure/defensive code can be written before the 
developer is admonished for being slow/late/etc.

While sloppy habits are one thing, it's entirely another to have 
management breathing down your neck, threatening to ship your job 
overseas, unless you get code out the door yesterday.

It's an environment that fosters insecure habits and resultant products. 
 I'm not talking about habits like using strncpy vs strcpy, I'm talking 
about validation of user input, ensuring a secure architecture to begin 
with, and the like.  The later takes far more time to impliment than is 
given in many environments.  The former requires sufficient 
specifications be given upfront - otherwise you have insufficient 
information to correctly use a function like strncpy.

Kind Regards,
-dsp
Michael Silk wrote:
Quoting from the article:
''You can't really blame the developers,''
I couldn't disagree more with that ...
It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra' or an 'added bonus'
in an application. Typically it's just about programming _correctly_!
The article says it's a 'communal' problem (i.e: consumers should
_ask_ for secure software!). This isn't exactly true, and not really
fair. Insecure software or secure software can exist without
consumers. They don't matter. It's all about the programmers. The
problem is they are allowed to get away with their crappy programming
habits - and that is the fault of management, not consumers, for
allowing 'security' to be thought of as something seperate from
'programming'.
Consumers can't be punished and blamed, they are just trying to get
something done - word processing, emailing, whatever. They don't need
to - nor should. really. - care about lower-level security in the
applications they buy. The programmers should just get it right, and
managers need to get a clue about what is acceptable 'programming' and
what isn't.
Just my opinion, anyway.
-- Michael
[...]



RE: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael S Hines
Wonder what happens if we apply that same logic to building design or bridge 
design and
contstruction? 

Those who don't place blame at the source are just trying to blame shift.   Bad 
idea..  

Mike Hines
---
Michael S Hines
[EMAIL PROTECTED] 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Silk
Sent: Wednesday, April 06, 2005 8:40 AM
To: Kenneth R. van Wyk
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?

Quoting from the article:
''You can't really blame the developers,''

I couldn't disagree more with that ...

It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra' or an 'added bonus'
in an application. Typically it's just about programming _correctly_!

The article says it's a 'communal' problem (i.e: consumers should
_ask_ for secure software!). This isn't exactly true, and not really
fair. Insecure software or secure software can exist without
consumers. They don't matter. It's all about the programmers. The
problem is they are allowed to get away with their crappy programming
habits - and that is the fault of management, not consumers, for
allowing 'security' to be thought of as something seperate from
'programming'.

Consumers can't be punished and blamed, they are just trying to get
something done - word processing, emailing, whatever. They don't need
to - nor should. really. - care about lower-level security in the
applications they buy. The programmers should just get it right, and
managers need to get a clue about what is acceptable 'programming' and
what isn't.

Just my opinion, anyway.

-- Michael


On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
 Greetings++,
 
 Another interesting article this morning, this time from eSecurityPlanet.
 (Full disclosure: I'm one of their columnists.)  The article, by Melissa
 Bleasdale and available at
 http://www.esecurityplanet.com/trends/article.php/3495431, is on the general
 state of application security in today's market.  Not a whole lot of new
 material there for SC-L readers, but it's still nice to see the software
 security message getting out to more and more people.
 
 Cheers,
 
 Ken van Wyk
 --
 KRvW Associates, LLC
 http://www.KRvW.com






Re: [SC-L] Mobile phone OS security changing?

2005-04-06 Thread Kenneth R. van Wyk
On Wednesday 06 April 2005 09:26, Michael Silk wrote:
 The last thing I want is my mobile phone updating itself. I imagine
 that sort of operation would take up battery power, and possibly cause
 other interruptions ... (can you be on a call and have it update
 itself?)

I vividly remember a lot of similar arguments a few years ago when desktop PCs 
started doing automatic updates of OS and app software.  Now, though, my 
laptop gets its updates when it's connected and when I'm not busy doing other 
things.

My main point, though, is that the status quo is unacceptable in my opinion.  
If a nasty vulnerability is found in most of today's mobile phone software, 
the repair process -- take the phone to the provider/vendor and have them 
burn new firmware -- just won't cut it.  For that matter, a lot of PDAs are 
in the same boat.

Sure, we'd all prefer better software in those devices to begin with, but as 
long as there are bugs and flaws, the users of these devices need a better 
way of getting the problems fixed.

 Personally, I would prefer a phone that doesn't connect to the
 internet at all rather than a so called 'secure' phone.

For the most part, those days are over.

 From reading the article it seems like the application asks to be
 installed, (is that correct?) so it doesn't seem like that big of a
 problem [unless phones start to get into the 'trusted'/'non-trusted'
 application area..]

Fortunately, no one would ever think of removing that query from the worm
or circumventing the mechanism in the OS, so that it copies itself without 
notice in the future.  ;-\

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Jeff Williams
I would think this might work, but I - if I ran a software development
company - would be very scared about signing that contract... Even if
I did everything right, who's to say I might not get blamed? Anyway,
insurance would end up being the solution.
What you *should* be scared of is a contract that's silent about security. 
Courts will have to interpret (make stuff up) to figure out what the two 
parties intended.  I strongly suspect courts will read in terms like the 
software shall not have obvious security holes.  They will probably rely on 
documents like the OWASP Top Ten to establish a baseline for trade practice.

Contracts protect both sides.  Have the discussion.  Check out the OWASP 
Software Security Contract Annex for a 
template.(http://www.owasp.org/documentation/legal.html).

--Jeff

- Original Message -
From: Michael Silk [EMAIL PROTECTED]
To: Kenneth R. van Wyk [EMAIL PROTECTED]
Cc: Secure Coding Mailing List SC-L@securecoding.org
Sent: Wednesday, April 06, 2005 9:40 AM
Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
 Quoting from the article:
 ''You can't really blame the developers,''

 I couldn't disagree more with that ...

 It's completely the developers fault (and managers). 'Security' isn't
 something that should be thought of as an 'extra' or an 'added bonus'
 in an application. Typically it's just about programming _correctly_!

 The article says it's a 'communal' problem (i.e: consumers should
 _ask_ for secure software!). This isn't exactly true, and not really
 fair. Insecure software or secure software can exist without
 consumers. They don't matter. It's all about the programmers. The
 problem is they are allowed to get away with their crappy programming
 habits - and that is the fault of management, not consumers, for
 allowing 'security' to be thought of as something seperate from
 'programming'.

 Consumers can't be punished and blamed, they are just trying to get
 something done - word processing, emailing, whatever. They don't need
 to - nor should. really. - care about lower-level security in the
 applications they buy. The programmers should just get it right, and
 managers need to get a clue about what is acceptable 'programming' and
 what isn't.

 Just my opinion, anyway.

 -- Michael


 On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
 Greetings++,

 Another interesting article this morning, this time from 
 eSecurityPlanet.
 (Full disclosure: I'm one of their columnists.)  The article, by 
 Melissa
 Bleasdale and available at
 http://www.esecurityplanet.com/trends/article.php/3495431, is on the
 general
 state of application security in today's market.  Not a whole lot of 
 new
 material there for SC-L readers, but it's still nice to see the 
 software
 security message getting out to more and more people.

 Cheers,

 Ken van Wyk
 --
 KRvW Associates, LLC
 http://www.KRvW.com








Re: [SC-L] Mobile phone OS security changing?

2005-04-06 Thread Michael Silk
On Apr 7, 2005 3:12 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
 On Wednesday 06 April 2005 09:26, Michael Silk wrote:
  The last thing I want is my mobile phone updating itself. I imagine
  that sort of operation would take up battery power, and possibly cause
  other interruptions ... (can you be on a call and have it update
  itself?)
 
 I vividly remember a lot of similar arguments a few years ago when desktop PCs
 started doing automatic updates of OS and app software.  Now, though, my
 laptop gets its updates when it's connected and when I'm not busy doing other
 things.

Hmm, I wasn't around then but I can see what you are saying... Still,
though, a phone seems so simple, and I can completely live without net
access (I guess they said this too) so it just seems wrong, and a
little annoying, to bring security problems to them...

 
 My main point, though, is that the status quo is unacceptable in my opinion.
 If a nasty vulnerability is found in most of today's mobile phone software,
 the repair process -- take the phone to the provider/vendor and have them
 burn new firmware -- just won't cut it.  For that matter, a lot of PDAs are
 in the same boat.

True. But I wonder if an update strategy like that allows them to be
more secure? I.e. perhaps a physical interface can allow more
programming options? Options that aren't available over the HTTP
interface (like installing apps, for example).

This could increase their security.

Corporations giving phones out to employee's, or developing software
for them, could buy these attachments and have policies at work.
Regular people would need to go back to the phone store, or a
speciality Mobile Phone Software Installer store to get it done.

 
 Sure, we'd all prefer better software in those devices to begin with, but as
 long as there are bugs and flaws, the users of these devices need a better
 way of getting the problems fixed.

Fair enough..


  Personally, I would prefer a phone that doesn't connect to the
  internet at all rather than a so called 'secure' phone.
 
 For the most part, those days are over.

I guess I better hold on to my 'non-internet' phone for as long as I
can, then, if I won't be able to replace it :)

-- Michael


 Cheers,
 
 Ken van Wyk
 --
 KRvW Associates, LLC
 http://www.KRvW.com




Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
Jeff,

On Apr 7, 2005 11:00 AM, Jeff Williams [EMAIL PROTECTED] wrote:
  I would think this might work, but I - if I ran a software development
  company - would be very scared about signing that contract... Even if
  I did everything right, who's to say I might not get blamed? Anyway,
  insurance would end up being the solution.
 
 What you *should* be scared of is a contract that's silent about security.

If you're silent you can claim ignorance :D

But of course, I agree. Security should be mentioned under the part
of applications Working Right.

What I meant I would be scared of, however, is that if the contract
didn't fully specify what I would be taking responsibility for. I.e. I
could be blamed if some misconfiguration on the server allowed a user
to run my tool/component as admin and enter some information or do
whatever.

The contract would have to be specific (technical?) so-as to avoid
problems like this. But I presume you have had far more experience
with these issues than I have... can you share any w.r.t to problems
like that?

Because I can imagine [if I wasn't ethical] trying to blame a security
problem in My Big Financial Website on a 3rd party tool if I could.


 Courts will have to interpret (make stuff up) to figure out what the two
 parties intended.  I strongly suspect courts will read in terms like the
 software shall not have obvious security holes.  They will probably rely on
 documents like the OWASP Top Ten to establish a baseline for trade practice.
 
 Contracts protect both sides.  Have the discussion.  Check out the OWASP
 Software Security Contract Annex for a
 template.(http://www.owasp.org/documentation/legal.html).

Yes, I've read the before, and even discussed it with you! :)

-- Michael

 
 --Jeff
 
 
  - Original Message -
  From: Michael Silk [EMAIL PROTECTED]
  To: Kenneth R. van Wyk [EMAIL PROTECTED]
  Cc: Secure Coding Mailing List SC-L@securecoding.org
  Sent: Wednesday, April 06, 2005 9:40 AM
  Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
 
   Quoting from the article:
   ''You can't really blame the developers,''
  
   I couldn't disagree more with that ...
  
   It's completely the developers fault (and managers). 'Security' isn't
   something that should be thought of as an 'extra' or an 'added bonus'
   in an application. Typically it's just about programming _correctly_!
  
   The article says it's a 'communal' problem (i.e: consumers should
   _ask_ for secure software!). This isn't exactly true, and not really
   fair. Insecure software or secure software can exist without
   consumers. They don't matter. It's all about the programmers. The
   problem is they are allowed to get away with their crappy programming
   habits - and that is the fault of management, not consumers, for
   allowing 'security' to be thought of as something seperate from
   'programming'.
  
   Consumers can't be punished and blamed, they are just trying to get
   something done - word processing, emailing, whatever. They don't need
   to - nor should. really. - care about lower-level security in the
   applications they buy. The programmers should just get it right, and
   managers need to get a clue about what is acceptable 'programming' and
   what isn't.
  
   Just my opinion, anyway.
  
   -- Michael
  
  
   On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
   Greetings++,
  
   Another interesting article this morning, this time from
   eSecurityPlanet.
   (Full disclosure: I'm one of their columnists.)  The article, by
   Melissa
   Bleasdale and available at
   http://www.esecurityplanet.com/trends/article.php/3495431, is on the
   general
   state of application security in today's market.  Not a whole lot of
   new
   material there for SC-L readers, but it's still nice to see the
   software
   security message getting out to more and more people.
  
   Cheers,
  
   Ken van Wyk
   --
   KRvW Associates, LLC
   http://www.KRvW.com
  
  
  
 
 
 





Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
On Apr 7, 2005 1:16 AM, Goertzel Karen [EMAIL PROTECTED] wrote:
 I think it's a matter of SHARED reponsibility. Yes, the programmers and
 their managers are directly responsible. But it's consumers who create
 demand, and consumers who, out of ignorance, continue to fail to make
 the connection between bad software security and the viruses, privacy,
 and other issues about which they are becoming increasingly concerned.

Quite frankly I don't think consumers need to care at all about this.

Do you, when buying chips, ask how they were cooked? Do you go back
and inspect the kitchen? Do you ask for a report on their compliance
to local health laws? No. The most you might do is glance at a box
with some ticks on it.

Why should software be any different? Why place the burden on
consumers to now evalutate the security of your products? Not only
don't they care, nor do they have the time, they wouldn't know where
to start!


 The consumer can't be held responsible for his ignorance...

Exactly!


 Because practioners of safe software have not done a very good
 job of getting the message out in terms that consumers, vs. other
 software practioners and IT managers, can understand.
 
 I propose that the following is the kind of message that might make a
 consumer sit up and listen:
 
 We understand that you buy software to get your work or online
 recreation done as easily as possible. But being able to get that work
 done WITHOUT leaving yourself wide open to exploitation and compromise
 of YOUR computer and YOUR personal information is also important, isn't
 it?

Answer: Duh.

 
 A number of software products, including some of the most popular ones,
 are full of bugs and other vulnerabilities that DO leave those programs
 wide open to being exploited by hackers so they can get at YOUR personal
 information, and take over YOUR computing resources.

Answer: So? I need to use them.

 
 Why is such software allowed to be sold at all? Because no-one
 regulates the SECURITY of the software products that these the companies
 put out, least of all the programmers who write that software. And, more
 importantly, because you the consumer hasn't been told before that you
 can make a difference. You can vote with your feet.

Answer: But how will I pay my GST next month if I can't use my
accounting program? I don't want to waste time transferring all my
data to another product...


 Demand that the software you use not be full of holes and 'undocumented
 features' that can be exploited by hackers.

Answer: How? I buy my software at a department store.

 
 If we can start to raise consumer awareness 

It's easy to blame the consumer - it means we
programmers/management/whatever don't need to do anything until they
ask us. But they will _never_ be able to ask all the right questions.
_Never_. So to put that requirement on them is just our 'easy way out'
of the problem.

-- Michael

 
 --
 Karen Goertzel, CISSP
 Booz Allen Hamilton
 703-902-6981
 [EMAIL PROTECTED]
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk
  Sent: Wednesday, April 06, 2005 9:40 AM
  To: Kenneth R. van Wyk
  Cc: Secure Coding Mailing List
  Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
 
  Quoting from the article:
  ''You can't really blame the developers,''
 
  I couldn't disagree more with that ...
 
  It's completely the developers fault (and managers). 'Security' isn't
  something that should be thought of as an 'extra' or an 'added bonus'
  in an application. Typically it's just about programming _correctly_!
 
  The article says it's a 'communal' problem (i.e: consumers should
  _ask_ for secure software!). This isn't exactly true, and not really
  fair. Insecure software or secure software can exist without
  consumers. They don't matter. It's all about the programmers. The
  problem is they are allowed to get away with their crappy programming
  habits - and that is the fault of management, not consumers, for
  allowing 'security' to be thought of as something seperate from
  'programming'.
 
  Consumers can't be punished and blamed, they are just trying to get
  something done - word processing, emailing, whatever. They don't need
  to - nor should. really. - care about lower-level security in the
  applications they buy. The programmers should just get it right, and
  managers need to get a clue about what is acceptable 'programming' and
  what isn't.
 
  Just my opinion, anyway.
 
  -- Michael
 
 
  On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
   Greetings++,
  
   Another interesting article this morning, this time from
  eSecurityPlanet.
   (Full disclosure: I'm one of their columnists.)  The
  article, by Melissa
   Bleasdale and available at
   http://www.esecurityplanet.com/trends/article.php/3495431,
  is on the general
   state of application security in today's market.  Not a
  whole lot of new
   material there for SC-L readers, but 

Re: [SC-L] Mobile phone OS security changing?

2005-04-06 Thread Crispin Cowan
Kenneth R. van Wyk wrote:
Greetings,
I noticed an interesting article about a mobile phone virus affecting 
Symbian-based phones out on Slashdot today.  It's an interesting read:

http://it.slashdot.org/it/05/04/06/0049209.shtml?tid=220tid=100tid=193tid=137
What particularly caught my attention was the sentence, Will mobile OS 
companies, like desktop OS makers, have to start an automatic update system, 
or will the OS creators have to start making their software secure?  Apart 
from the author implying that this is an or situation,

I think it is definitely an or situation: automatic updates are 
expensive to provision and fugly for the user. They are just a kludge 
used when, for some reason, the software canot be made secure.

That the desktop vendor (Microsoft) has not made their software secure 
is manifestly obvious. Whether the can't or won't is subject to 
rampant debate and speculation. The can't view says that legacy 
software and fundamentally broken architecture make securing it 
infeasible. The won't view says that it was not profitable for MS to 
spend the effort, and they are now changing.

That the alternate desktop vendors (all the UNIX and Linux vendors 
including Apple) have made secure desktops is also manifestly obvious 
(no viruses to speak of, and certainly no virus problem). Whether this 
is luck or design is subect to rampant debate and speculation. The 
luck view says that these minority desktops are not a big enough 
target to be interesting to the virus writers. The design view is that 
the virus problem is induced by: 1. running the mail client with 
root/administrator privilege, and 2. a mail client that eagerly trusts 
and executes attached code, and that until UNIX/Linux desktops have both 
of those properties in large numbers, there never will be a virus 
problem on UNIX/Linux desktops.

What the phone set people will do depends on which of the above factors 
you think apply to phone sets. Certainly the WinCE phones with Outlook 
are about to be virus-enabled. I don't know enough about Symbian to 
answer. The Linux hand sets could be designed either way; it would not 
surprise me to see phone set peole architecting a phone so that the 
keyboard is root. It is not exactly intuitive to treat a hand set as a 
multi-user platform.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com



Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-06 Thread Michael Silk
Inline

On Apr 7, 2005 1:06 AM, Dave Paris [EMAIL PROTECTED] wrote:
 And I couldn't disagree more with your perspective, except for your
 inclusion of managers in parenthesis.
 
 Developers take direction and instruction from management, they are not
 autonomous entities.  If management doesn't make security a priority,

See, you are considering 'security' as something extra again. This is
not right.

My point is that management shouldn't be saying 'Oh, and don't forget
to add _Security_ to that!' The developers should be doing it by
default.


 then only so much secure/defensive code can be written before the
 developer is admonished for being slow/late/etc.

Then defend yourself ... ! Just as you would if the project was too
large due to other reasons. Don't allow security to be 'cut off'.
Don't walk in and say 'Oh, I was just adding security to it,'. A
manager will immediately reply: Oh, we don't care about that
Instead say: Still finishing it off... (This _has_ worked for me in
the past, by the way...)

 
 While sloppy habits are one thing, it's entirely another to have
 management breathing down your neck, threatening to ship your job
 overseas, unless you get code out the door yesterday.

Agreed. (Can't blame consumers for this issue, however..)

 
 I'm talking
 about validation of user input, 

This is something that all programmer should be doing in _ANY_ type of
program. You need to handle input correctly for your app to function
correctly, otherwise it will crash with a dopey user.


 ensuring a secure architecture to begin
 with, and the like.  

'Sensible' architecture too, though. I mean, that's the whole point of
a design - it makes sense. For example, an app may let a user update
accounts based on ID's, but it doesn't check if the user actually owns
the ID of the account they are updating. They assume it's true because
they only _showed_ them ID's they own.

You'd hope that your 'sensible' programmer would note that and confirm
that they did, indeed, update the right account. Not only for security
purposes, but for consistency of the _system_. The app just isn't
doing what it was 'specified' to do if the user can update any
account. It's _wrong_ - from a specification point of view - not just
'insecure'.

You would, I guess, classify this as something the managers/consumers
need to explicitly ask for. To me, it seems none of their business. As
a manager, you don't want to be micromanaging all these concepts (but
we are - CIO's...) they should be the sole responsibility of the
programmer to get right.


 The later takes far more time to impliment than is
 given in many environments.  The former requires sufficient
 specifications be given upfront 

Agreed.

-- Michael


 Michael Silk wrote:
  Quoting from the article:
  ''You can't really blame the developers,''
 
  I couldn't disagree more with that ...
 
  It's completely the developers fault (and managers). 'Security' isn't
  something that should be thought of as an 'extra' or an 'added bonus'
  in an application. Typically it's just about programming _correctly_!
 
  The article says it's a 'communal' problem (i.e: consumers should
  _ask_ for secure software!). This isn't exactly true, and not really
  fair. Insecure software or secure software can exist without
  consumers. They don't matter. It's all about the programmers. The
  problem is they are allowed to get away with their crappy programming
  habits - and that is the fault of management, not consumers, for
  allowing 'security' to be thought of as something seperate from
  'programming'.
 
  Consumers can't be punished and blamed, they are just trying to get
  something done - word processing, emailing, whatever. They don't need
  to - nor should. really. - care about lower-level security in the
  applications they buy. The programmers should just get it right, and
  managers need to get a clue about what is acceptable 'programming' and
  what isn't.
 
  Just my opinion, anyway.
 
  -- Michael
 [...]