[SC-L] How Can You Tell It Is Written Securely?

2008-11-27 Thread Mark Rockman
OK.  So you decide to outsource your programming assignment to Asia and demand 
that they deliver code that is so locked down that it cannot misbehave.  How 
can you tell that what they deliver is truly locked down?  Will you wait until 
it gets hacked?  What simple yet thorough inspection process is there that'll 
do the job?  Doesn't exist, does it?


MARK ROCKMAN
MDRSESCO LLC  ___
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] Disable Bounds Checking?

2007-11-03 Thread Mark Rockman
Back around 1980, when Ada was new, it was common for compiler manufacturers to 
claim it is best to disable bound checking for performance reasons.  Getting 
your program to run slightly faster trumped knowing that any of your buffers 
was overflowing. Code that silently trashes memory can be expected to produce 
some truly creative results.   My practice is to code defensively, to ensure my 
program is operating according to policies that I set for it.  I want to know 
when it is misbehaving.  Should there be a performance hit, I instrument the 
program to find the hot spots and optimize those and only those.___
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] COBOL Exploits

2007-11-02 Thread Mark Rockman
The adolescent minds that engage in exploits wouldn't know COBOL if a 
printout fell out a window and onto their heads.  I'm sure you can write COBOL 
programs that crash, but it must be hard to make them take control of the 
operating system.  COBOL programs are heavy into unit record equipment (cards, 
line printers), tape files, disk files, sorts, merges, report writing -- all 
the stuff that came down to 1959-model mainframes from tabulating equipment.  
They don't do Internet.  What they could do and have done is incorporate 
malicious code that exploits rounding error such that many fractional pennies 
end up in a conniving programmer's bank account.___
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] Programming languages -- the third rail of secure coding

2004-07-21 Thread Mark Rockman
JOVIAL goes back to the 1960s as Jules' Own Version of the International
Algebraic Language.
ALGOL and IAL are the same thing.  JOVIAL was used almost exclusively by the
United States Air Force.

- Original Message - 
From: Dave Aronson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 11:05
Subject: Re: [SC-L] Programming languages -- the third rail of secure
coding


 Michael S Hines [EMAIL PROTECTED] wrote:

   I've been compiling a list of programming languages..

 You missed FORTRAN, ICON, REXX, SNOBOL, and the assorted OS-based shell
 scripting languages (bash/csh/ksh/etc., VMS DCL, DOS .bat, etc.).  I've
 heard of JOVIAL, which I *think* is a programming language used almost
 exclusively in the US military.  Since a few companies make things that
 translate it into code, you might consider UML as well.  Then there are
 a gazillion languages for particular commercial packages -- you got
 Oracle's PL/SQL, but there are also dBase/Clipper, FrEd (Framework
 Editor, from an old integrated office suite), Lotus 1-2-3 macros, and
 many more.

 Also, depending on your definition of programming language (versus
 markup language and a few other types), you might have a few extras as
 well.

 -- 
 David J. Aronson, Contract Software Engineer in Washington DC area
 Resume and other information online at: http://destined.to/program






Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

2004-07-06 Thread Mark Rockman
You are not nuts.  Your course outline  is a very substantial step in the
right direction.
- Original Message - 
From: Dana Epp [EMAIL PROTECTED]
To: Fernando Schapachnik [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 06, 2004 16:42
Subject: Re: [SC-L] Education and security -- another perspective (was ACM
Queue - Content)


  I'd be interested to hear what people think of the two approaches
(separate
  security courses vs. spreading security all over the curricula).
 
  Regards.
 
  Fernando.

 Well, I have been asked to teach a new forth year course at the British
 Columbia Institute of Technology (BCIT) this fall on Secure Programming
 (COMP4476). I have no problem sharing my course outline and breakdown,
 since a lot of this is adopted from experiences many other structured
 secure programming courses and literature are taking. The idea is that
 students need to build a strong foundation of learning that they can
 adopt in which ever discipline they follow in the future. This shouldn't
 be a first year course, but I think its a bit late being a fourth year
 course. You will note that the course I am teaching is somewhat language
 agnostic, and even platform agnostic to ensure that the foundation isn't
 tainted with 'fad-of-the-day' techniques, technologies and tools. (Hold
 that to Web applications, which the jury is still out on)

 Course Breakdown
 
 1. Essentials of Application Security
 * Types of attacks (hackers, DoS, Viruses, Trojans, Worms,
 organizational attacks etc)
 * Consequences of Poor Security (Data theft, lost productivity, damage
 reputation, loose consumer confidence, lost revenues)
 * Challenges when Implementing Security (Security vs Usability,
 Attackers vs Defenders, The misinformation about the security cost)

 2. Secure Application Development Practices
 * Implementing security at every stage of the development process
 * Designing clean error code paths, and fail securely
 * Planning on Failure through results checking
 * Code review

 3. Threat Modeling
 * Attack Trees
 * STRIDE Threat Modeling
 * DREAD risk analysis

 4. Using Security Technologies
 * Encryption
 * Hashing
 * Digital signatures
 * Digital certificates
 * Secure communications (Using IPSec/SSL)
 * Authentication
 * Authorization

 5. Detecting and fixing Memory and Arithmetic Issues
 * Buffer overflows
 * Heap overflows
 * Integer overflows

 6. Defending against Faulty Inputs and Tainted Data
 * User input validation techniques
 * Regular expressions
 * Parameter checking
 * Fault injection reflection

 7. Design, Develop and Deploy software through least privilege
 * Running in least privilege
 * Developing and debugging in least privilege
 * Providing secure defaults using the Pareto Principle
 * Applying native OS security contexts to processes and files (ACL,
 perms etc)

 8. Securing Web applications
 * C14N
 * SQL Injection
 * Cross-site scripting
 * Parameter checking

 As I complete the lesson plan this summer this outline will change. I
 think more study on understanding trusted and untrusted boundaries needs
 to be added, and some areas such as Threat Modeling will be flushed out
 with more detail. Overall though, you can get an idea of areas of
 education that I feel make up a core foundation of learning in secure
 programming. I wish I could take credit for this thinking, as its a
 strong foundation to build on. Alas I cannot; pick up any number of
 secure coding books and realize that this is all covered there in some
 degree:

 * Building Secure Code
 * Secure Coding Principles  Practices
 * Secure Programming Cookbook
 * Security Engineering
 * Building Secure Software

 I only wish I could make all these books be textbook requirements for
 the curriculum. It should be mandatory reading. Although you can teach
 some aspects in any course being provided, the reality is I think a
 dedicated course helps to build on the real foundation of learning. All
 other courses can re-enforce these teachings to further drive it home
 for the student.

 Of course, I also think students should have to take at least one course
 in ASM to really understand how computer instructions work, so they can
 gain a foundation of learning for the heart of computer processing. And
 I think they should be taught the powers and failures of C. Since I know
 many of you think I'm nuts for that, you might want to look at this
 outline with the same amount of consideration.

 -- 
 Regards,
 Dana Epp
 [Blog: http://silverstr.ufies.org/blog/]