It's only possible to automate what can be formally described.
Unless a programmer conveniently comments his sections of "malicious"
code as such, I can think of no criteria that would make "malicious"
COBOL code (or code in any other language) readily distinguishable by
manual or automatic scanning from normal complex business logic. Some
coding practices jump out visually as "bad" because they are highly
unstructured and and difficult to maintain, or because of repeated use
of constructs that are known to be inefficient; but this only relates to
programming competence, not malicious intent.
If the original program requirements specifications were so precise and
complete as to leave nothing to the discretion of the programmer, then
there might be some hope of verifying that everything in the actual code
had a one-to-one relationship with the specifications - but then you
would simply move the search for malicious intent from the source code
to the design specifications, and in effect have the same problem.
Your best bet for catching malicious code is for 3rd-party
review/testing/auditing of code by someone familiar with the intended
function of the code and who understands what result fields and related
manipulation are especially sensitive and deserve special close
examination. It goes without saying that an application should not be
accessing files or database tables that are unrelated to the functional
specifications of the application, but that requires an understanding of
the explicit and implicit requirements of the design, not just an
examination of the code. Application design, implementation, and code
analysis continue to be complex tasks requiring both art and science.
There are good philosophical and logical reasons why after many decades
of interest in automated programming it continues to prove impossible to
eliminate humans from the programming design and implementation process.
Automation for detection of "malicious" code in the PC world - and we
all know this malware detection is imperfect - is only possible because
the definition has been narrowed considerably to (1) detection of code
signatures unique to programs that have been found by empirical evidence
to do bad things; (2)heuristic detection of programs that modify or
access files and/or system data to which they should not have access.
Security systems on MVS pretty well shut the door on these generic kinds
of attacks.
JC Ewing
Itschak Mugzach wrote:
I've tried iehiball many times in the past ;-) There must be a way to
automate it.
On 8/11/08, Chase, John <[EMAIL PROTECTED]> wrote:
-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Itschak Mugzach
I know some products that checks program complexity, and even
those who look into specific command usage. But this time I
am looking for a product to analyse mainframe traditional
language (Cobol, PLI, etc) for malicious code.
I have some ideas like the usage of string command, Input
that come outside a file record, etc.
What are you using to analyse your code?
IEHIBALL.
-jc-
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
