Essential Skills for Secure Programmers Using Java/JavaEE

Source: WebWare

Security

The Secure Programming Council unveiled a proposed standard for companies to test their software developer’s knowledge of secure programming. The aim is to create a situation in which companies can ensure that their developers, whether in-house or outsourced, have a base

level of knowledge about wrapping security into software applications.

The council is rolling out its “Essential Skills for Secure Programmers Using Java/JavaEE” (pdf), the first of six standards initiatives. It plans to later add skills tests for C and C++, as well as languages .Net, PHP, and PERL.

The council is opening up the Java/JavaEE proposed standard for public comment via e-mail over the next 60 days. Some of the proposed areas of testing will include data handling, authentication, and session management and access control. For example, under the data handling task, Java programmers must be able to write programs that read input from interfaces, properly validate the data, then disseminate it. The programmers would also need to be familiar with such malicious-attack scenarios as cross-site scripting and SQL injections.

The skill testing is designed to not only ask developers whether they know what encryption is but whether they understand the differences between PKI encryption and other forms of encryption, said Ryan Berg, co-founder of Ounce Labs and a member of the Secure Programming Council’s Java and JavaEE steering committee.

More than 40 companies, government agencies, and security firms have participated in helping to establish the standards, largely coming from the financial services, manufacturing, aerospace, military, and outsourcing industries, said Alan Paller, director of research at SANS Institute.

“One large financial institution has told its developers that they had to pass the test by August 1, or they won’t touch a line of code,” Paller said. “The financial industry is taking the lead because they have the most to lose.”

SANS will administer the tests, which are scheduled to begin on December 5 in London and continue for the next eight months in cities through out the United States and Europe. Where the admission fee will be between $50 and $450, for participants ranging from students to employees of large corporations.

I must say that I can only applaud such an effort. Security shouldn’t be considered a “nice-to-have”, but a “must-have” within the development cylcle.

Check out GSSP @ Sans

Advertisements

Grinder : Load Testing Framework

What is Grinder?

The Grinder is a Java load-testing framework. It is freely available under a BSD-style open-source license. The Grinder makes it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application. Test scripts make use of client code embodied in Java plug-ins. Most users of The Grinder do not write plug-ins themselves, instead they use one of the supplied plug-ins. The Grinder comes with a mature plug-in for testing HTTP services, as well as a tool which allows HTTP scripts to be automatically recorded.

How can I use it? A small tutorial…
Continue reading “Grinder : Load Testing Framework”

“hsperfdata_”-files in /tmp (or $TMPDIR) – jstat

The “hsperfdata_”-files are part of the java performance monitoring since version 1.4.2.
A general FAQ can be found here. A part of this performance monitoring aspect is “jstat”. It’s a Java SE bundled command-line JVM statistics monitoring tool.

To see what type of statistics you can choose from:
jstat -options

For example, to see a summary of garbage of collection statistics:
jstat -gcutil

[root@pingu:/tmp]# ls /tmp/hsperfdata_sandbox/
4828 4843 5024 5081
[root@pingu:/tmp]# jstat -gcutil 4828
S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 98.11 74.98 38.82 94.05 23 1.033 1 0.181 1.213

A syntax explanation on howto use “jstat” can be found here.

Java in real-time systems?

Today developerWorks published an interesting article on their site.

Some big clue lines:

Real-Time requirements

Real-time (RT) is a broad term used to describe applications that have real-world timing requirements. For example, a sluggish user interface doesn’t satisfy an average user’s generic RT requirements. This type of application is often described as a soft RT application. The same requirement might be more explicitly phrased as “the application should not take more than 0.1 seconds to respond to a mouse click.” If the requirement isn’t met, it’s a soft failure: the application can continue, and the user, though unhappy, can still use it. In contrast, applications that must strictly meet real-world timing requirements are typically called hard RT applications. An application controlling the rudder of an airplane, for example, must not be delayed for any reason because the result could be catastrophic. What it means to be an RT application depends in large part on how tolerant the application can be to faults in the form of missed timing requirements.

As you might guess, using Java for such RT (Real-Time) applications isn’t that obvious. A small summary of the challenges:
– Standard Java provides no guarantees for thread scheduling or thread priorities : It’s quite hard for an application to reacte within a given time if the trhead management doesn’t support this.
– Java-conformant JVM must delay loading a class until it’s first referenced by a program : This causes a delay in the application, and also in the Real-Time response of the applications. As the delay can cause an significant (& possibly unexpected) impact. The same goes for compiling to native code.
– Garbage collection: The GC can cause delays too, and same as the above… and thus cause an impact.

And then some promo on how IBM solves this matter… 😉 Yet it remains interesting reading material if you’re working with Java applications in an environment that depends on performance. It gives you some extra insight on how to tune your machines/code.