MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Secure coding

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
ravi.alpha
Beginner


Joined: 31 Mar 2009
Posts: 18
Topics: 7

PostPosted: Sun May 10, 2009 11:21 pm    Post subject: Secure coding Reply with quote

I am coding set of program in COBOL with CICS and DB2 for online and COBOL, DB2 and JCL for batch process.

I want to make my code 100% secure. To do this I need to follow all the possible to secure coding practices.

Could you please provide me all the possible coding standards that I need to follow?

Your help is much appreciated.
Back to top
View user's profile Send private message
Terry_Heinze
Supermod


Joined: 31 May 2004
Posts: 391
Topics: 4
Location: Richfield, MN, USA

PostPosted: Mon May 11, 2009 3:43 pm    Post subject: Reply with quote

What exactly do you mean by "make my code 100% secure" and "secure coding practices"? What are you trying to accomplish?
_________________
....Terry
Back to top
View user's profile Send private message Send e-mail
semigeezer
Supermod


Joined: 03 Jan 2003
Posts: 1014
Topics: 13
Location: Atlantis

PostPosted: Mon May 11, 2009 9:41 pm    Post subject: Reply with quote

The mainframe, at least with standard COBOL and CICS, is not a stack based architecture so if you are thinking about junk like buffer overruns, code injection, cross site scripting and other workstation based nonsense, it probably won't happen in your code. Theoretically I suppose it is possible to exploit problems in runtime modules, authorized code and system level stuff like SVCs and exits but you'd have to work at a system level to write code that vulnerable. I do know of examples where people have written SVCs that exposed fetch protected memory, and I suppose one could modify a return register in a save area to branch to unintended code -- wait -- I've done that so I know it is possible. Just be smart and never write data to a place you do not know has system level security in place (like temp files that aren't RACF protected and automatically scratched, off site FTP or web sites, your local PC, etc). Don't write sensitive data to any logs or debug files (dumps are another matter). Use compiler features like array subscript checking if you can. And never confuse the presumed ignorance of your user with "security" (by that I mean "if he doesn't know about this parameter that
brings down the system, then he can never use it"). For what it is worth, I am guilty of doing several of these exploitable things over the years but never in anything that could be considered a mission critical or secure system. Basically, if you ever get the nagging feeling that something you are working on has some vulnerability, it almost certainly does; find it and fix it or redesign it.

Security exposures your code will face are more likely beyond your control. Unencrypted transmissions, poor firewalls, "social engineering", lost data backups, and bad site and/or data security are more likely to cause problems than bad COBOL coding. If you want to get into data encryption, access authentication, and other traditional security technologies, there are better places to look than a platform specific bulletin board, but most likely your site has whole departments already dedicated to those issues.

If by "online" you mean web based, then you should read as much as you can about how web based applications can be tampered with (scripting tricks, method overriding, spoofing, AJAX, etc), but as the person programming the 'back end' applications, even that stuff is outside of your control. Just be aware of verifying a requester's credentials in any questionable situation IF that is your responsibility. Again, more than likely all of the access controls should already be in place based on the userid assigned to your transactions or programs.

Obviously, I have no idea what I'm talking about, but if you need instruction in data security and potential pitfalls, you should hire some expertise from a security firm or IBM to give you formal instruction. I know IBM has (or at least used to have) people dedicated to helping people avoid security problems in system code and, one would assume, application code. At the very least, contact your system security people, talk with your boss (he or she should thank you for asking!) and find the most experienced people you can in your organization to ask them about horror stories, rumors of past problems, and their own practices.
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
Back to top
View user's profile Send private message Visit poster's website
ravi.alpha
Beginner


Joined: 31 Mar 2009
Posts: 18
Topics: 7

PostPosted: Mon May 11, 2009 11:07 pm    Post subject: Reply with quote

Let me put the whole senario.

If you check out https://www.securecoding.cert.org you will find out secure coding standard for C and Java. Smilarly I need to find secure coding standard for COBOL and use them in my coding. If some one of you have secure coding standard for COBOL please share it with me.
Back to top
View user's profile Send private message
semigeezer
Supermod


Joined: 03 Jan 2003
Posts: 1014
Topics: 13
Location: Atlantis

PostPosted: Tue May 12, 2009 12:58 am    Post subject: Reply with quote

Great site. Thanks for that.

I have seen some publications that have similar info for mainframe languages. The security and program loading environment is very different than, say Java but there certainly are concerns analogous to the ClassLoader problems (and similar problems) mentioned. In the MVS case, the system does a very good job of insuring that you can't inject unauthorized code among authorized code, for example, but since your code is probably not going to run authorized it is a good idea to understand the loading process (how load modules are found and loaded).

As for coding techniques like data conversions, initialization, precision loss, immutability and the like, the manuals IBM provided with the compilers, specifically the ones called Programmer's Guide (or similar, as opposed to language reference) often have these kinds of guidelines in them. I don't know exactly where you'd find the broader system or application guidelines such as program search orders, etc, but the authorized assembler services guide used to have a lot of the minutia and some security guidelines.

And of course, most of the rules at the site you pointed us to probably have corresponding rules in any system that just differ based on the language, runtimes or operating system (stuff like conversions or avoiding XML or SQL injection).
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
Back to top
View user's profile Send private message Visit poster's website
RonB
Beginner


Joined: 02 Dec 2002
Posts: 93
Topics: 0
Location: Orlando, FL

PostPosted: Tue May 12, 2009 8:22 am    Post subject: Reply with quote

A few things to think about vis-a-vis COBOL / Security:
1) If you feel that there is a need, "obfuscate" your COBOL source by substituting non-intelligible labels for all references, etc. ( note: you can purchase vendor packages to accomplish this ).
2) Unless necessary, do not specify BY REFERENCE, either implicitly or explicitly, on a CALL...USING... statement. This will prevent a CALLED program from obtaining an address in the CALLING program's Working-Storage or Linkage section(s).
3) If necessary, insure that the executable module is placed into a library marked "execute only", to prevent attempts to read the executable module and reverse-engineer it.
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.
Back to top
View user's profile Send private message
ravi.alpha
Beginner


Joined: 31 Mar 2009
Posts: 18
Topics: 7

PostPosted: Thu May 14, 2009 12:23 am    Post subject: Reply with quote

Thanks Ron B.

The points really help me to kick start my thinking. If you have some more similar kind of thoughts pls share it.
Back to top
View user's profile Send private message
ravi.alpha
Beginner


Joined: 31 Mar 2009
Posts: 18
Topics: 7

PostPosted: Thu May 14, 2009 12:32 am    Post subject: Reply with quote

Even if some one is having COBOL coding standards or Best practice suggestion pls shares it.
Back to top
View user's profile Send private message
DaveyC
Moderator


Joined: 02 Dec 2002
Posts: 151
Topics: 3
Location: Perth, Western Australia

PostPosted: Mon May 18, 2009 2:52 am    Post subject: Reply with quote

All brilliant answers by semigeezer.

I don't think that an LE COBOL program can run authorized. LE is designed for key 8 programs and would choke when initializing the environment. AFAIK, the only way to call an authorized LE program is to use CEEPIPI to create an authorized environment and then jump through lots of hoops.
_________________
Dave Crayford
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group